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Preface 


The KA680 CPU Module Technical Manual documents the functional, physical, 
and environmental characteristics of the KA680 CPU module, and includes 
information on the MS690 memory expansion modules. 


Organization 


The manual is divided into three parts. 


Overview and Installation 


Chapter 1, “Overview,” introduces the KA680 CPU module, the MS690 
memory module, and the H3604 console module, including module features 
and specifications. 


Chapter 2, “Installation and Configuration,” describes the procedures for 
installing and configuring the CPU, memory, and console modules in the 
Q22-bus backplanes and system enclosures. 


Architecture 


Chapter 3, “Central Processor,” describes the functions of the central 
processing unit. 


Chapter 4, “KA680 Cache Memory Overview,” describes the operation of the 
KA680 CPU module’s cache memory. 


Chapter 5, “KA680 Main Memory System,” describes the operation of the 
KA680 CPU module’s main memory. 


Chapter 6, “KA680 I/O Subsystem,” describes the I/O system configuration, 
along with the NCA chip architecture. 


Chapter 7, “The Console Line, TOY Clock,” describes the console serial line 
and the time-of-year clock. The chapter also provides an overview of the 
KA680 bus system. 


Chapter 8, “KA680 Boot and Diagnostic Facility,” describes the boot and 
diagnostic registers, EPROM memory, battery backed-up RAM and hardware 
initialization. 

Chapter 9, “KA680 Q22-bus Interface,” describes the interfaces the KA680 
CPU module uses for the Q22—bus. 


Chapter 10, “ Network Interface,” describes the network interface of the 
KA680. 


Chapter 11, “ KA680 Mass Storage Interface,” describes the interfaces the 
KA680 CPU module uses for the mass storage bus. 
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Firmware 


Chapter 12, “KA680 Firmware,” describes the entry dispatch code, boot 
diagnostics, device booting sequence, console program, and console commands. 


Appendices 


Appendix A, “NVRAM Partitioning,” describes how the KA680 firmware 
partitions the SSC 1 Kb battery backed-up (BBU) RAM. 


Appendix B, “Data Structures,” describes the global data structures used by 
the KA680 firmware. 


Appendix C, “ Error Messages ,” describes the error messages for the KA680, 
including machine check register dumps, halt codes, VMB error messages, 
and console error messages. 


Appendix D, “Machine State on Powerup,” describes the state of the KA680 
after a power-up halt. 


Appendix E, “MOP Support,” describes the maintenance operation protocol 
(MOP) support features in the KA680 firmware. 


Appendix F, “Q22-bus Specification,” describes the specifications for the 
Q22-bus. 


Appendix G, “Specifications,” describes the physical, electrical, and 
environmental characteristics of the KA680 CPU module. 


Appendix H, “VAX Instruction Set,” is a list of the VAX instructions, provided 
for reference only. 


Appendix I, “Address Assignments,” provides a map of VAX memory space. 


Appendix J, “Configurable Machine State,” provides a list of all configurable 
bits in the CPU module that are left after the successful completion of 
power-up RAM diagnostics. 


Conventions 
The following table lists the conventions used in this manual. 


Table 1 Conventions 


Convention Meaning 


<x:y> Represents a bit field, a set of lines, or signals, ranging from x through 


y. For example, RO <7:4> Indicates bits 7 through 4 in a general- 
purpose register RO. 


[x:y] Represents a range of bits, from y through x. 

Return A label enclosed in a box represents a key (usually a control or a special 
character key) on the keyboard (in this case, the return key). 

Note Contains general information. 

Caution Contains information to prevent damage to equipment. 

n Indicates a variable. 


Represents a console command element that is optional. 
Represents a console command element. 


Represents a list of command elements. 


CPU Refers to the NVAX central processor chip used in this design. 


Related Documents 
The following documents are related to the KA680 CPU. 


¢ Microcomputer Interfaces Handbook (EB-20175-20) 

¢ Microcomputers and Memories Handbook (EB-18451-20) 
¢ VAX Architecture Handbook (EB-19580-20) 

¢ VAX-11 Architecture Reference Manual (EK-VAXAR-RM) 
You can order these documents by phone or mail. 
Continental USA and Puerto Rico 

Call 800-258-1710 or mail to: 


Digital Equipment Corporation 
P.O. Box CS2008 
Nashua, NH 03061 


New Hampshire, Alaska, and Hawaii 
Call 1-603-884-6660. 

Outside the USA and Puerto Rico 
Mail to: 


Digital Equipment Corporation 
Attn: Accessories and Supplies Business Manager 
c/o Local Subsidiary or Digital-Approved Distributor 


XXV 


1 


Overview 


1.1 Introduction 
This chapter briefly describes the KA680 CPU/memory subsystem. 


The KA680 CPU module combines with the MS690 memory modules to form the 
CPU/memory subsystem for the VAX 4000-500 product. The subsystem is housed 
in the BA440 enclosure. The subsystem uses the DSSI bus to communicate with 
mass storage devices and the Q22-bus to communicate with I/O devices. A single 
KA680 CPU module can support up to four MS690 memory modules. Figure 1-1 
is a block diagram of the CPU/memory subsystem’s major functions. 


Figure 1-1 KA680 Module in a System 
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The KA680 can be configured only as an arbiter CPU on the Q22-bus, where 

it arbitrates bus mastership and fields bus interrupt requests and any on-board 
interrupt requests. The module uses multiple levels of cache memory to maximize 
performance. It is designed for use in high-speed, real-time applications and for 
multiuser, multitasking environments. 


The KA680 and the MS690 designs are implemented in fingerless quad-height 
sized modules. Both use high-density, right angle connectors and mount in 
dedicated slots in the backplane. The CPU uses a 270-pin backplane connector 
while the memory module uses a 150-pin connector. 
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The CPU module communicates with the memory modules across a memory 
interconnect routed through the high-density connectors and the backplane. The 
backplane connector also connects the subsystem with the Q22-bus and one DSSI 
bus. There are no jumpers or switches to configure on the processor module. 
Fuses are located on the H3604 console module. The KA680 connects to the 
H38604 console module with a 100-pin ribbon cable. The console module contains 
configuration switches, Ethernet and DSSI connectors, and an LED display. 


1.2 KA680 CPU Module 


1-2 Overview 


Figure 1—2 is a photograph of the KA680 CPU Module. 


Figure 1-2 KA680 CPU Module 


photograph of the MS690 memory module 
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The major hardware components of the KA680 CPU module are listed below. The 
chip identification numbers are shown in Figure 1-3. 


« DC246 Central processor (NVAX) 
« Cache RAMs A 128 KB backup cache - 

« DC243 NDAL to CDAL I/O bus interface chip (NCA) 
« DC244 Main memory controller, with ownership bit control (NMC) 
« DC527 Q22-bus interface (CQBIC) 
« DC541 Ethernet interface (SGEC) 
« DC542 DSSI interface chips (2) (SHAC) 
« DC511 System support chip (SSC) 

« DC509 Clock (CCLK) 
« Firmware ROMs (4) 512 KB; each 128 KB by 8, FLASH programmable - 

« Console Connection 100-pin ribbon cable to the H3604 console module - 


« Backplane Connection 270-pin ribbon cable to the backplane carrying signals for — 
the Q22-bus, the DSSI bus, and the memory interconnect 


Figure 1—3 shows the positions of the major chips on the KA680. 


Figure 1-3 KA680 CPU Module Component Side 
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Figure 1—4 shows the major functional blocks of the KA680 CPU module. 
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Figure 1-4 KA680 CPU Module Block Diagram 
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Functionally, the KA680 CPU module is divided into four major areas: 
¢ The central processing subsystem 

¢ The system support subsystem 

¢ The I/O subsystem 

¢ The memory control subsystem 


The H3604 is described in Section 1.4. 


1.2.1 The Central Processing Subsystem 


The central processing subsystem includes the NVAX CPU chip with an integral 
floating-point accelerator and a 3-level cache architecture. The RAM storage for 
the third level of cache (backup cache) is located on the CPU module. 


1.2.1.1 The NVAX Central Processing Unit (DC246) 


1-4 Overview 


The NVAX CPU (DC246) chip is the heart of the KA680 module. It executes the 
VAX base instruction group as defined by the VAX Architecture Standard plus 
the optional VAX vector instructions and the virtual machine instructions. A 
complete listing of the instructions executed by the CPU is given in Appendix H. 
The NVAX processor also supports full VAX memory management with demand 
paging and a 4-gigabyte virtual address space. 


For the rest of this document the NVAX CPU chip will be referred to simply as 
the "CPU," or "central processor," or "NVAX." 


The central processor supports the VAX base instruction set with the following 
string instructions: 
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e CMPC3 e CMPC5 e LOCC 
e MOVC3 e MOVC5 e SCANC 
e SKPC e SPANC 


The central processor provides the following subset of the VAX data types: 


e Byte e Word e Longword 
¢ Quadword e Character string e Variable-length bit field 
e F-floating e G-floating e D-floating 


Support for the remaining VAX data types can be provided through macrocode 
emulation. 


1.2.1.2 The Cache Memory 
The KA680 processor module uses a 3-level cache architecture to maximize 
performance. The first level of cache, referred to as the virtual instruction cache 
(VIC), is 2 kilobytes (KB), and is located in the CPU chip. This cache handles 
instructions only (no data references), and deals only with virtual addresses. 
In this way, the CPU can obtain instruction information without the need for 
virtual to physical address translation, thereby decreasing latency and improving 
performance. 


The second level of cache, referred to as the primary cache (Pcache), is 8 kilobytes 
in size and is located in the CPU chip. This cache implements a write-through 
instruction and data cache, and helps to reduce latency on access to instructions 
that are not found in the VIC. The Pcache uses physical addresses. 


The third level of cache, referred to as the backup cache (Bcache), stores 
instruction and data, and is 128 KB in size. The Bcache is controlled by the 
Bcache controller located in the CPU chip. The data and tag store memory for 
this cache is located in SRAM chips on the KA680 module. The Bcache uses 
physical addresses. 


1.2.2 The System Support Subsystem 


The system support subsystem handles the basic functions required to support 
the console in a system environment. This subsystem contains the system 
support chip (SSC), the firmware ROMs, the boot and diagnostic register, and the 
station address ROM. 


1.2.2.1 The System Support Chip [SSC (DC511)] 


The SSC chip is in an 84-pin CERQUAD surface mount package. It provides 
console and boot code support functions, operating system support functions, 
timers, and the following features: 


¢ ROM address decoding 

¢ 1 KB battery backed-up RAM 

¢ Halt-arbitration logic 

¢ Console serial line 

¢ VAX standard time-of-year clock with battery backup 
¢ JIORESET register 
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Programmable CDAL bus timeout 
Two programmable timers 


Register controlling the diagnostic LEDs 


1.2.2.2 The Firmware ROMs 
Resident firmware ROM is located on four chips, each 128K by 8 bits of FLASH® 
programmable EPROMs, for a total of 512 KB of ROM. The firmware gains 


control when the CPU halts, and contains programs that provide the following 
services: 


Board initialization 
Power-up self-testing of the KA680 and MS690 modules 


Emulation of a subset of the VAX standard console (auto or manual bootstrap, 
auto or manual restart, and a simple command language for examining or 
altering the state of the processor) 


Booting from supported Q22-bus and DSSI devices 


Multilingual translation of key system messages 


1.2.2.3. The Boot and Diagnostic Register 


The boot and diagnostic register (BDR) allows the firmware and the operating 
system to read KA680 configuration bits. 


1.2.2.4 The Station Address ROM 


The station address ROM contains the network hardware address of the system. 
It is implemented in a 32 byte by 8 bit ROM (6331). 


1.2.3 The I/O Subsystem 
The I/O subsystem contains the following: 


CP-bus adapter 
DSSI mass storage interfaces 
An Ethernet interface 


A Q22-bus interface 


1.2.3.1 NVAX CP-bus Bus Adapter [NCA (DC243)] 


In order to provide buffering and connection to the I/O devices, the KA680 contains an NCA 
(DC243). The NCA provides an interface between the NVAX NDAL bus and two CP-buses 
where the the I/O device adapters reside. The CP-buses do not leave the KA680 module. As 

a bus adapter, the NCA controls transactions between the higher performance NDAL bus and 
the lower performance CP-buses. Each of the NCA’s CP-bus ports provides a CVAX compatible 
peripheral bus for direct memory access (DMA) by peripheral devices. The NCA is in a 339-pin 


PGA package. 


* A FLASH EPROM is a programmable read-only memory that uses electrical (bulk) 
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1.2.3.1.1 DSSI Mass Storage Interface [SHAC (DC542)] The two shared-host 
adapter chips (SHAC) implement the DSSI (Digital storage system interconnect) 
bus interfaces. One SHAC interfaces to the system console module while the 
other SHAC interfaces to the system backplane. The DSSI interface allows each 
DSSI bus on the KA680 to transmit packets of data to, and receive packets from, 
up to seven other DSSI devices. The SHAC facilitates scatter and gather mapping 
along with internal FIFO buffering, and features parity protection during data 
transfers to and from the CPU and main memory. 


The DSSI bus improves system performance because it has a higher transfer rate 
than the Q22-bus and it relieves the Q22—-bus of disk traffic. The DSSI bus has 
eight data lines, one parity line, and eight control lines. Controllers are built into 
the integrated storage elements (ISEs), enabling many functions to be handled 
without host or adapter intervention. 


1.2.3.1.2 Ethernet Interface [SGEC (DC541)] The Ethernet interface handles 
communications between the CPU module and other nodes on the Ethernet. 

It is implemented with the second generation Ethernet controller chip (SGEC, 
DC541) on-board network interface. Used in connection with the H3604 console 
module, the SGEC allows the KA680 to connect to either a ThinWire or standard 
Ethernet. It supports the Ethernet Data Link Layer and provides CP-bus parity 
protection. The SGEC chip is in an 84-pin package. The chip facilitates scatter 
and gather mapping along with dual internal FIFO buffering. 


1.2.3.1.3  Q22-bus Interface [CQBIC (DC527)] The KA680 includes a Q22—bus 
interface that allows communication between the KA680 and other devices on the 
bus. It is implemented with the CP-bus to Q22—bus asynchronous adapter chip 
(CQBIC, DC527). The CQBIC is in a 132-pin CERQUAD surface mount package. 
The KA680 does not provide Q22—bus termination; the backplane provides the 
termination resistors. The Q22—bus interface supports the following functions: 


¢ Scatter/gather mapping functions 


¢ Masked and unmasked longword reads and writes from CPU to the Q22—bus 
memory and I/O space and the CQBIC registers 


¢ Up to 16-word, block mode writes from Q22—bus to main memory 
¢ Up to 2-word, block mode transfers between the CPU and Q22-bus devices 
¢ Transfers from CPU to local Q22—bus memory space 


1.2.4 The Memory Control Subsystem 


This subsystem provides support for the KA680 memory subsystem. A key 
feature of the KA680 memory subsystem is the use of ownership bits to maintain 
a sense of ownership over each hexaword (32 bytes) of main memory. This 
ownership mechanism serves the dual function of maintaining coherency between 
main memory and the NVAX cache memory, as well as providing a secure 
interlock mechanism for synchronization between NVAX and the I/O devices. 
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1.2 KA680 CPU Module 


1.2.4.1. NVAX Memory Controller [NMC (DC244)] 


The memory controller is implemented by the NVAX memory controller 

chip (DC244). The NMC is an ECC! memory controller. The NMC controls 
transactions between the main memory and the NVAX, and between main 
memory and any of the I/O devices (CQBIC, SGEC, and the two SHAC chips). In 
addition, the NMC has a key role in maintaining main memory coherency with 
the NVAX primary and backup caches through the use of ownership bits. 


The NMC interfaces the NVAX and I/O subsystem with up to four memory 
modules. The NMC controls access to shared memory locations through the 
use of the ownership bits, thereby providing a reliable interlock mechanism for 
memory that is shared between the NVAX and the I/O devices. 


1.3 MS690 Memory Module 


The MS690 is a double-sided memory board, in a 72-bitwide array (64-bit data 
and 8-bit error correction code). Two versions will be offered; one implemented 
with 1 Mb DRAM chips and another version using 4 Mb DRAM chips. The 
version using 1 Mb DRAMs will contain 32 MB per module, and the version using 
4 Mb DRAMs will contain 64 MB or 128 MB per module. 


The module mounts in a dedicated memory backplane slot. It is fingerless and 
uses a 150-pin high density, right angle connector to connect to the backplane. 


1.4 H3604 Console Module 
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The H38604 console module (Figure 1—5) allows the KA680 CPU module to 
interface to a serial line console device, a DSSI bus, and to the Ethernet. The 
H38604 module is wide enough to cover the five slots dedicated to the KA680 and 
its four MS690 modules. Five adhesive tags are included for the user to name the 
modules in the respective slots. 


1 ECC stands for error checking and correction. 
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Figure 1-5 H3604 Console Module Front 
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The H3604 contains the following connectors to allow CPU communication: 


A console serial line with baud rate switch 
Two Ethernet connectors, with a switch to choose between them 


Two DSSI connectors (50-pin high density) that allow daisy chaining of one 
DSSI bus; terminators for both DSSI connectors; and two DSSI BUS ID select 
plugs 


The H3604 also has four feature selection switches: 


Baud rate select switch for the serial console line. 
Power-up mode switch. 


Break enable/disable switch. This determines whether the CPU may be 
"halted", causing execution to jump to the halt restart firmware. If halts are 
enabled, then the CPU may be halted from the console keyboard in one of 
two ways, depending on the setting of bit 15 of the SSC configuration register 
(SSCCR<15>). Refer to Section 12.2.2 for more information regarding halts. 
If this switch is set to the enable position (1), the system does not autoboot on 
powerup. It enters console I/O mode and displays the >>> prompt. 


Ethernet connector switch to select the following: 
— A 15-conductor connector for standard Thickwire Ethernet cable. 


— Amale BNC connector for a ThinWire Ethernet coaxial cable. 


LEDs indicate the selected connector and valid +12 Vdc for that connector. 
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In addition, the H3604 contains the following features: 


Console serial line drivers and receivers 
Hexadecimal display 

Battery charger and low-voltage detect 
25.6 KHz TOY clock oscillator 

-9 V dce/dc converter 

Ethernet serial interface adapter chip (SIA) 


Fused current surge protection 


The door of the H3604 contains a DSSI circuit fuse and two plugs. The fuse is to 
protect against shorts from the accidental grounding of the DSSI cable power pin. 
The external node ID plugs are used to select the host adapter numbers. Node 
number 7 is preset to both of the SHAC DSSI bus controllers on the CPU board. 
(The two DSSI buses are separate.) 


There are two connectors from the H3604 to the internal BA440. One is a 4-pin 
power connection to a small printed circuit card that inserts into the backplane 
alongside the KA680. The other is the 100-pin connector to the KA680 CPU 
module. 
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Installation and Configuration 


This chapter describes how to install the KA680 in a system. It discusses the 
following topics: 


¢ Installing the KA680 and MS690 modules 
¢ Configuring the KA680 
¢ KA680 connectors 


2.1 Installing the KA680 and MS690 Memory Modules 
Note 


You can use the KA680 and MS690 modules only in BA440 system 
enclosures that use high-density backplane connector slots. 


The KA680 CPU module and the MS690 memory modules must be installed 
in the five rightmost backplane slots. Note that the KA680 module installs in 
backplane slot J5, and the memory modules install in slots J4 through J1. 


To install the KA680 and MS690 modules: 
1. Install the KA680 CPU in slot J5 of the backplane. 


2. Install MS690 memory modules in slots J4 through J1 next to to the KA680 
CPU. 


¢ Ifyou only use one memory module , you can install it in any of the slots 
J4 through J1. 


¢ If you use more than one memory module, you must install the first 
memory module in J4, the second in J3, and so on. Do not leave a gap 
between memory modules. 


3. Install a 100-pin ribbon cable between the KA680 CPU and the console 
module. 


Figure 2-1 shows the positions of the KA680 CPU and the memory modules in 
the backplane. 
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Figure 2-1 Backplane 
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2.2 Module Configuration and Naming 


Each Q22-bus module in a system must use a unique device address and 
interrupt vector. The device address is also known as the control and status 
register (CSR) address. Most modules have switches or jumpers for setting the 
CSR address and interrupt vector values. The value of a floating address depends 
on what other modules are housed in the system. 
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Set CSR addresses and interrupt vectors for a module as follows: 


1. Determine the correct values for the module with the CONFIG command at 
the console I/O prompt (>>>). The CONFIG utility eliminates the need to 
boot the VMS operating system to determine CSRs and interrupt vectors. 
Enter the CONFIG command, then HELP for the list of supported devices: 


>>> CONFIG 

Enter device configuration, HELP, or EXIT 
Device, Number? HELP 

Devices: 

LPV11 KXJ11 DLV11d DZQ11 
RLV21 TSV05 RXV21 DRV11W 
DMV11 DELQA DEQNA RQDX3 
RQC25 KXXXX-DISK TQK50 TQK70 
KXXXX-TAPE KMV11 IEQ11 DHQ11 
CXB16 CXY08 VCB02 QDSS 
vsv21 IBQ01 IDV11A IDV11B 
IAV11A IAV11B MIRA ADQ32 
IGQ11 


DZV11 
DRV11B 
KDA50 
TU81E 
DHV1] 
DRV11 
IDV1] 
DTC04 


ag 


DFAQ1 
DPV11 
RRD50 
RV20 
CXA16 
DRQ3B 
IDV11D 
DESOA 


The LPV11-SA has two sets of CSR address and interrupt vectors. To 
determine the correct values for an LPV11-SA, enter LPV11,2 at the DEVICE 
prompt for one LPV11-SA, or enter LPV11,4 for two LPV11-SA modules. 


2. See the KA680 CPU System Maintenance Manual for switch settings and CSR 
and interrupt vector jumper settings for supported options. 


2.3 Mass Storage Configuration 


There is space for four mass storage devices—either three integrated storage 
elements (ISEs) and one tape drive, or four ISEs. The ISEs are part of the Digital 


storage system interconnect (DSSD bus. 


The DSSI bus is part of the backplane. The ISEs are part of the RF-series, and 
they plug into the backplane to become part of the bus. Each ISE must have 
its own unique DSSI node ID. The ISE receives its node ID from a plug on the 
operator control panel (OCP) on the front panel. 


The VMS operating system creates DSSI disk device names according to the 


following scheme: 
nodename $ DIA unit number 
For example: 


SUSANSDIA3 


You can use the device name for booting, as follows: 


>>> BOOT SUSANSDIA3 
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You can access local programs in the RF-series ISE through the MicroVAX 
diagnostic monitor (MDM), or through the VMS operating system and console 
I/O mode SET HOST/DUP command. This command creates a virtual terminal 
connection to the storage device and the designated local program using the 
diagnostic and utilities protocol (DUP) standard dialog. Section 2.3.3 describes 
the procedure for accessing DUP through the VMS operating system. 


2.3.1 Changing the Node Name 


Each ISE has a node name that is maintained in EPROM on board the controller 
module. This node name is determined in manufacturing from an algorithm 
based on the drive serial number. You can change the node name of the DSSI 
device to something more meaningful by following the procedure in Example 2-1. 
In the example, the node name for the ISE at DSSI node address 1 is changed 
from R3YBNE to DATADISK 


Example 2-1 Changing a DSSI Node Name 


>>> SHO DSSI 
DSSI Node 0 (MDC) 


-DIAO (RF71) 

DSSI Node 1 (R3YBNE) 'The node name for this drive will be 
-DIA1 (RF71) 'changed from R3YBNE to DATADISK. 
DSSI Node 7 (*) 

>>> 


>>> SET HOST/DUP/DSSI 1 
Starting DUP server... 
Copyright 1988 Digital Equipment Corporation 


DRVEXR V1.0 D 5-NOV-1988 15:33:06 
DRVTST V1.0 D 5-NOV-1988 15:33:06 
HISTRY V1.0 D 5-NOV-1988 15:33:06 
ERASE V1.0 D 5-NOV-1988 15:33:06 
PARAMS V1.0 D 5-NOV-1988 15:33:06 
DIRECT V1.0 D 5-NOV-1988 15:33:06 


End of directory 
Task Name? params 
Copyright 1988 Digital Equipment Corporation 


PARAMS> SHO NODENAME 


Parameter Current Default Type Radix 


NODENAME R3YBNE RF71 String Ascii B 


PARAMS> SET NODENAME DATADISK 


PARAMS> WRITE !This command writes the change 
'to EEPROM. 
Changes require controller initialization, ok? [Y/(N)] ¥ 


Stopping DUP server... 
>>> SHO DSSI 
DSSI Node 0 (MDC) 


-DIAO (RF71) 
DSSI Node 1 (DATADISK) 'The node name has changed from 
-DIA1 (RF71) 'R3YBNE to DATADISK. 


DSSI Node 7 (*) 
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2.3.2 Changing the DSSI Unit Number 


By default, the ISE drive assigns the disk’s unit number to the same value as the 
DSSI node address for that drive. 


Example 2—2 shows how to change the unit number of a DSSI device. This 
example changes the unit number for the RF71 drive at DSSI node address 

1 from 1 to 50 (decimal). You must change two parameters: UNITNUM and 
FORCEUNI. Changing these parameters overrides the default, which assigns the 
unit number the same value as the node address. 


Example 2-2 Changing a DSSI Unit Number 


>>> SHO DSSI 
DSSI Node 0 (MDC) 


-DIAO (RF71) 

DSSI Node 1 (R3QUNE) 'The unit number for this drive will be 
-DIA1 (RF71) ‘changed from 1 to 50 (DIA1 to DIA50). 
DSSI Node 7 (*) 

>>> 


>>> SET HOST/DUP/DSSI 1 
Starting DUP server... 
Copyright 1988 Digital Equipment Corporation 


DRVEXR V1.0 D 5-NOV-1988 15:33:06 
DRVTST V1.0 D 5-NOV-1988 15:33:06 
HISTRY V1.0 D 5-NOV-1988 15:33:06 
ERASE V1.0 D 5-NOV-1988 15:33:06 
PARAMS V1.0 D 5-NOV-1988 15:33:06 
DIRECT V1.0 D 5-NOV-1988 15:33:06 


End of directory 

Task Name? PARAMS 

Copyright 1988 Digital Equipment Corporation 
PARAMS> SHO UNITNUM 


Parameter Current Default Type Radix 


PARAMS> SHO FORCEUNI 


Parameter Current Default Type Radix 


FORCEUNI 1 1 Boolean 0/1 U 
PARAMS> SET UNITNUM 50 
PARAMS> SET FORCEUNI 0 
PARAMS> WRITE 'This command writes the changes to EEPROM. 


PARAMS> EX 
Exiting... 


Task Name? 


Stopping DUP server... 
>>> 

>>>SHO DSSI 

DSSI Node 0 (MDC) 
-DIAO (RF71) 


(continued on next page) 
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Example 2-2 (Cont.) Changing a DSSI Unit Number 


DSSI Node 1 (R3QJUNE) 'The unit number has changed 
-DIA50 (RF71) ‘and the node ID remains at 1. 


DSSI Node 7 (*) 


2.3.3 Accessing RF-series Firmware in VMS Through DUP 


You can also access the RF-series ISE firmware utilities from the VMS operating 
system as well as through the console commands. 


Use the VMS operating system to access the ISE firmware if you want to look 
up or view parameter settings, but not change them. To change ISE parameter 
settings, enter the ISE firmware through the console I/O mode SET HOST/DUP 
command. 


Load the FYDRIVER using the following commands in SYSGEN: 


$ MCR SYSGEN 

SYSGEN> LOAD FYDRIVER/NOADAPTER 
SYSGEN> CONNECT FYA0/NOADAPTER 
SYSGEN> EXIT 

$ 


You can then access the ISE firmware utilities by using the following VMS 
command: 


$ SET HOST/DUP/SERVER=MSCPSDUP/TASK=PARAMS nodename 


2.3.3.1 Allocation Class 


2-6 


When a KA680 system containing ISEs is configured in a cluster, either as a boot 
node or a satellite node, you must assign the allocation class in VMS SYSGEN 
and for the ISE matching nonzero values. To change the allocation class of the 
ISE, use the following commands: 


>>> SET HOST/DUP/DSSI <DSSI node number> PARAMS 
Starting DUP server.. 


PARAMS> SET ALLCLASS <allocation class value> 


PARAMS> WRITE 
Changes require controller initialization, ok? [Y/N] ¥ 


Stopping DUP server.. 
>>> 
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2.4 DSSI Cabling, Device Identity, and Bus Termination 


The ISEs in one particular BA440 enclosure are connected to the system 
backplane and communicate internally over the backplane. There are no internal 
DSSI cables. Externally, a 50-pin cable connects the DSSI bus to other devices, 
either hosts or expanders. 


There are two DSSI ports in the KA680 system. One DSSI port is routed along 
the backplane and exits the enclosure at the left edge from a connector near the 
ISE slots. The other DSSI port is configured by means of the DSSI connector on 
the H3604 panel. If unused, DSSI connectors must be terminated. 


There is no terminator on the KA680. The near-end termination is contained 
on the backplane for the internal DSSI bus, and is provided by the pluggable 
connectors for the external bus. 


All DSSI devices on the same bus must have unique identifiers. On the face 

of the H3604 console module, you can see the two DSSI bus node ID plugs 
(Figure 1-5). These ID plugs provide an identity for each DSSI bus. Because the 
DSSI controllers implemented by the SHAC chips on the KA680 CPU module are 
separate, the two ID plugs may be identical. 


2.5 KA680 Connectors 


The KA680 CPU module uses two connectors, J1 and J2. J1 is a 270-pin 
connector that mates with the backplane. J2 is the connector for the 100-pin 
ribbon cable that goes to the console module. Users configure the KA680 through 
the H3604 console module. Figure 1—3 shows the location of the connectors on 
the KA680 module. 


Installation and Configuration 2-7 


3 


Central Processor 


The central processor of the KA680 supports the MicroVAX chip subset (plus six 
additional string instructions) of the VAX instruction set, and datatypes and full 
VAX memory management. It is implemented with a single VLSI chip called the 
NVAX (DC246). 


3.1 Processor State 


The processor state consists of that portion of the state of a process stored in 
processor registers rather than in memory. The processor state is composed of 
sixteen general-purpose registers (GPRs), the processor status longword (PSL), 
and the internal processor registers (IPRs). 


Nonprivileged software can access the GPRs and the processor status word (bits 
<15:00> of the PSL). The IPRs and bits <31:16> of the PSL can only be accessed 
by privileged software. The IPRs are explicitly accessible only by the move to 
processor register (MTPR) and move from processor register (MFPR) instructions, 
which can be executed only while running in kernel mode. 


3.1.1 General-Purpose Registers 


The KA680 implements 16 general-purpose registers. as implemented per the 
VAX Architecture Reference Manual These registers are used for temporary 
storage, accumulators, and base and index registers for addressing. These 
registers are denoted RO—R15. The bits of a register are numbered from the 
right <0> through <31>. Figure 3-1 shows the general-purpose register format. 
Table 3-1 describes the registers. 


Figure 3-1 General-Purpose Register 


31 00 
LJ-01323-T10 


Some of these registers have been assigned special meaning by the VAX—11 
architecture: 
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Table 3-1 General-Purpose Register Description 


Register Register Name Mnemonic Description 


R15 Program Counter PC The PC contains the address 
of the next instruction byte 
of the program. 


R14 Stack Pointer SP The SP contains the address 
of the top of the processor 
defined stack. 


R13 Frame Pointer FP The VAX-11 procedure call 
convention builds a data 
structure on the stack called 
a stack frame. The FP 
contains the address of the 
base of this data structure. 


R12 Argument Pointer AP The VAX-11 procedure 
call convention uses a 
data structure called an 
argument. The AP contains 
the address of the base of 
this data structure. 


Consult the VAX Architecture Reference Manual for more information on the 
operation and use of these registers. 


3.1.2 Processor Status Longword 


The KA680 processor status longword (PSL) is implemented per the VAX 
Architecture Reference Manual, which should be consulted for a detailed 
description of the operation of this register. The PSL is saved on the stack 
when an exception or interrupt occurs and is saved in the process control 

block (PCB) on a process context switch. Bits <15:00> may be accessed by 
nonprivileged software, while bits <31:16> may only be accessed by privileged 
software. Processor initialization sets the PSL to 041F 0000 4g. Figure 3-2 shows 
the processor status longword format. Table 3—2 lists the bits and definitions. 


Figure 3-2 Processor Status Longword 


31 30 29 28 27 26 25 24 23 22 21 20 16 15 08 07 06 05 04 03 02.01 00 
Cur | PRV 
MBZ 
CM FPD MBZ DV | Iv 
TP IS FU 
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Note 


VAX Compatibility Mode instructions can be emulated by macrocode, but 
the emulation software runs in native mode, so the CM bit is never set. 


Table 3—2 explains the properties of each internal process register: 


Table 3-2 Internal Process Register Definitions 


PSL Data 

Bit Name Definition 

<31> CM Compatibility Mode. This bit always reads as zero, loading a one 
into this bit is a NOP. 

<30> TP Trace Pending. 

<29:28> MBZ Must Be written as Zero. 

<27> FPD First Part Done. 

<26> IS Interrupt Stack. 

<25:24> CUR Current Mode. 

<23:22> PRV Previous Mode. 

<21> MBZ Must Be written as Zero. 

<20:16> IPL Interrupt Priority Level. 

<15:8> MBZ Must Be written as Zero. 

<7> DV Decimal Overflow trap enable. This read/write bit has no effect 
on KA680 hardware; it can be used by macrocode that emulates 
VAX decimal instructions. 

<6> FU Floating Underflow fault enable. 

<5> IV Integer Overflow trap enable. 

<4> T Trace trap enable. 

<3> N Negative condition code. 

<2> Z Zero condition code. 

<I> Vv Overflow condition code. 

<0> C Carry condition code. 


3.1.3 Internal Processor Registers 


The processor registers that are implemented by the NVAX CPU chip, and those 
that are required of the system environment, are logically divided into five 
groups, as follows: 


¢ Normal—Those IPRs that address individual registers in the NVAX CPU chip 
or system environment. 


¢ Bcache tag IPRs—The read/write block of IPRs that allow direct access to the 
Beache tags. 


¢ Bcache deallocate IPRs—The write-only block of IPRs by which a Bcache 
block may be deallocated. 


¢ Pcache tag IPRs—The read/write block of IPRs that allow direct access to the 
Pcache tags. 
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¢ Pcache data parity IPRs—The read/write block of IPRs that allow direct 
access to the Pcache data parity bits. 


Each group of IPRs is distinguished by a particular pattern of bits in the IPR 
address, as shown in Figure 3-3. 
Figure 3-3 IPR Address Space Decoding 
Normal IPR Address 


31 25 24 23 08 07 00 


SBZ 0 SBZ IPR Number 


Bcache Tag IPR Address 


31 25 24 23 22 21 20 19 18 17 16 05 04 00 


Bcache Deallocate IPR Address 
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Pcache Data Parity IPR Address 


25 24 23 22 21 13 12 11 10 05 04 03 02 


Sublock Select 
Pcache Set Select (0=Left, L=Right) 
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The numeric range for each of the four groups is shown in Table 3-3. 


Table 3-3 IPR Address Space Decoding 
IPR Address Range 


IPR Group Mnemonic’ (hex) Contents 
Normal - 00000000..000000FF? 256 individual IPRs 
Bcache Tag BCTAG 01000000..0107FFEK0? 16K Bcache tag IPRs, each 


separated by 20(hex) from the 
previous one 


Bcache Deallocate BCFLUSH  01400000..0147FFE0” 16K Bcache tag deallocate 
IPRs, each separated by 
20(hex) from the previous 
one 


Pcache Tag PCTAG 01800000..01801FE0* 256 Pcache tag IPRs, 128 
for each Pcache set, each 
separated by 20(hex) from the 
previous one 


Pcache Data Parity PCDAP 01C00000..01C01FF8? 1024 Pcache data parity IPRs, 
512 for each Pcache set, each 
separated by 8(hex) from the 
previous one 


IThe mnemonic is for the first IPR in the block. 


?Unused fields in the IPR addresses for these groups should be zero. Neither hardware nor microcode 
detects and faults on an address in which these bits are nonzero. Although noncontiguous address 
ranges are shown for these groups, the entire IPR address space maps into one of these groups. If 
these fields are nonzero, the operation of the CPU is UNDEFINED. 


Note 


The address ranges shown above are those used by the programmer. 
When processing normal IPRs, the microcode shifts the IPR number left 
by 2 bits for use as an IPR command address. This positions the IPR 
number to bits <9:2> and modifies the address range as seen by the 
hardware to 0..3FC, with bits <1:0>=00. No shifting is performed for the 
other groups of IPR addresses. 


Because of the sparse addressing used for IPRs in groups other than the normal 
group, valid IPR addresses are not separated by one. Rather, valid IPR addresses 
are separated by either 8 or 20(hex). For example, the IPR address for Bcache tag 
0 is 01000000 (hex), and the IPR address for Bcache tag 1 is 01000020 (hex). In 
this group, bits <4:0> of the IPR address are ignored, so IPR numbers 01000001 
through 0100001F all address Bcache tag 0. Similarly, the IPR address for the 
first subblock of Pcache data parity is 01C00000 (hex), and the IPR address for 
the second subblock of Pcache data parity is 01C00008 (hex). 


Processor registers in all groups except the normal group are processed entirely 
by the NVAX CPU chip and will never appear on the NDAL (Section 3.11). This 
is also true for a number of the IPRs in the normal group. IPRs in the normal 
group that are not processed by the NVAX CPU chip are converted into I/O space 
references and passed to the system environment via a read or write command on 
the NDAL. 
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Central Processor 
3.1 Processor State 


Each of the 256 possible IPRs in the normal group are of longword length, so a 
1 KB block of I/O space is required to convert each possible IPR to a unique I/O 
space longword. This block starts at address E1000000 (hex). Conversion of an 
IPR address to an I/O space address in this block is done by shifting the IPR 
address left into bits <9:2>, filling bits <1:0> with zeros, and merging in the base 
address of the block. This can be expressed by the equation 


IO ADDRESS = £1000000 + (IPR NUMBER « 4) 


The actual hardware implementation of this is different in that the IPR number 
is shifted left by 2 bits, and bits <31:29,24> are set. There is no multiplying or 
adding done as one might conclude from the equation. 


Because many of the 256 possible IPRs in the normal group are processed entirely 
by the NVAX CPU chip, the corresponding I/O space location in the 1 KB block is 
never referenced as a result of an MTPR/MFPR to or from these IPRs. However, 
note that a programmer can indeed reference these locations via an explicit 

I/O space reference (for example, MOVL). References to this block of I/O space 
locations with instructions other than MTPR/MFPR may result in UNDEFINED 
behavior. 


The processor registers implemented by the NVAX CPU are shown in Table 3-4. 


Note 


Many of the processor registers listed in Table 3-4 are used internally 
by the microcode during normal operation of the CPU, and are not 
intended to be referenced by software except during test or diagnosis of 
the system. These registers are flagged with the notation “Testability 
and diagnostic use only; not for software use in normal operation.” 
References by software to these registers during normal operation can 
cause UNDEFINED behavior of the CPU. 
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Table 3-4 Processor Registers 


Number 
Register Name Mnemonic (Dec) (Hex) Type ImpI Cat 1/O Address 
Kernel Stack Pointer KSP 0 0 RW NVAX 1-1 - 
Executive Stack Pointer ESP 1 1 RW NVAX 1-1 - 
Supervisor Stack Pointer SSP 2 2 RW NVAX 1-1 - 
User Stack Pointer USP 3 3 RW NVAX 1-1 - 
Interrupt Stack Pointer ISP 4 4 RW NVAX 1-1 - 
Reserved - 5 5 - - 3 E1000014 
Reserved - 6 6 - - 3 E1000018 
Reserved - 7 7 - - 3 E100001C 
PO Base Register POBR 8 8 RW NVAX 1-2 - 
PO Length Register POLR 9 9 RW NVAX 1-2 - 
P1 Base Register P1IBR 10 A RW NVAX 1-2 - 
P1 Length Register P1LR 11 B RW NVAX 1-2 - 
System Base Register SBR 12 C RW NVAX 1-2 - 
System Length Register SLR 13 =D RW NVAX 1-2 - 
CPU Identification CPUID 14 +#&E RW NVAX 2-1 - 
Reserved - 15 F - - 3 E100003C 
Process Control Block Base PCBB 16 10 RW NVAX 1-1 - 
System Control Block Base SCBB 17 11 RW NVAX 1-1 - 
Type: 


R = Read-only register 
RW = Read/write register 
W = Write-only register 


Impl(emented): 


NVAX = Implemented in the NVAX CPU chip 
System = Implemented in the system environment 
Vector = Implemented in the optional vector unit or its NDAL interface 


Cat(egory), class-subclass, where: 


class is one of: 


1 = Implemented per DEC Standard 032 
2 = NVAX-specific implementation that is unique or different from the DEC Standard 032 implementation 
3 = Not implemented internally; converted to I/O space read or write and passed to system environment 


subclass is one of: 


1 = Processed as appropriate by Ebox microcode 

2 = Converted to Mbox IPR number and processed via internal IPR command 

3 = Processed by internal IPR command, then converted to I/O space read or write and passed to system environment 
4 = If virtual machine option is implemented, processed as in 1; otherwise, as in 3 

5 = Processed by internal IPR command 

6 = May be block decoded; reference causes UNDEFINED behavior 

ae Full interval timer may be implemented in the system environment. Subset ICCS is implemented in NVAX CPU 
chip 

8 = Converted to MFVP MSYNC 


(continued on next page) 
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3.1 Processor State 


Table 3-4 (Cont.) Processor Registers 


Register Name 


Number 
Mnemonic (Dec) (Hex) Type Impl 


Cat l/O Address 


Interrupt Priority Level! 
AST Level* 


Software Interrupt Request Register 


Software Interrupt Summary Register! 


Reserved 

Reserved 

Interval Counter Control/Status 
Next Interval Count 

Interval Count 

Time of Year Register 

Console Storage Receiver Status 


Console Storage Receiver Data 


IPL 18 12 RW NVAX 
ASTLVL 19 18 RW NVAX 
SIRR 20 14 W # £NVAX 
SISR 21 15 RW NVAX 


- 22 160 «= - = 
= 23 17) - - 


ICCS 24 18 RW NCA 
NICR 25 19 RW NCA 
ICR 26 1A RW NCA 


TODR 27 1B RW _ SSC 
CSRS 28 1C RW _ SSC 
CSRD 29 1D R SSC 


1-1 - 
1-1 - 
1-1 - 
1-1 - 
3 E1000058 
3 E100005C 
2-7 E1000060 
3-7 E1000064 
3-7 E1000068 
2-3 E100006C 
2-3 E1000070 
2-3 E1000074 


lnitialized on reset 


Type: 
R = Read-only register 
RW = Read/write register 
W = Write-only register 


Impl(emented): 


NVAX = Implemented in the NVAX CPU chip 
System = Implemented in the system environment 


Vector = Implemented in the optional vector unit or its NDAL interface 


Cat(egory), class-subclass, where: 


class is one of: 


1 = Implemented per DEC Standard 032 


2 = NVAX-specific implementation that is unique or different from the DEC Standard 032 implementation 
3 = Not implemented internally; converted to I/O space read or write and passed to system environment 


subclass is one of: 


1 = Processed as appropriate by Ebox microcode 


2 = Converted to Mbox IPR number and processed via internal IPR command 
3 = Processed by internal IPR command, then converted to I/O space read or write and passed to system environment 
4 = If virtual machine option is implemented, processed as in 1; otherwise, as in 3 


5 = Processed by internal IPR command 


6 = May be block decoded; reference causes UNDEFINED behavior 
7 = Full interval timer may be implemented in the system environment. Subset ICCS is implemented in NVAX CPU 


chip 
8 = Converted to MFVP MSYNC 
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Table 3-4 (Cont.) Processor Registers 


Central Processor 


3.1 Processor State 


Register Name 


Number 
Mnemonic (Dec) (Hex) Type Impl 


Cat 1/O Address 


Console Storage Transmitter Status 
Console Storage Transmitter Data 
Console Receiver Control/Status 
Console Receiver Data Buffer 
Console Transmitter Control/Status 
Console Transmitter Data Buffer 
Reserved 

Reserved 

Machine Check Error Register 
Reserved 

Reserved 

Reserved 

Console Saved PC 

Console Saved PSL 


CSTS 

CSTD 
RXCS 
RXDB 
TXCS 
TXDB 


30 
31 
32 
33 
34 
35 
36 
37 
38 
39 
40 
41 
42 
43 


1E 
1F 
20 
21 
22 
23 
24 
25 
26 
27 
28 
29 
2A 
2B 


RW 


SSC 2-3 E1000078 
SSC 2-3 E100007C 
SSC 2-3 E1000080 
SSC 2-8 E1000084 
SSC 2-3 E1000088 
SSC 2-3 E100008C 
- 3 E1000090 
= 3 E1000094 
NVAX 2-1 - 

- 3 E100009C 
- 3 E10000A0 
- 3 E10000A4 
NVAX 2-1 - 

NVAX 2-1 - 


Type: 
R = Read-only register 
RW = Read/write register 
W = Write-only register 
Imp](emented): 


NVAX = Implemented in the NVAX CPU chip 


System = Implemented in the system environment 
Vector = Implemented in the optional vector unit or its NDAL interface 


Cat(egory), class-subclass, where: 


class is one of: 


1 = Implemented per DEC Standard 032 


2 = NVAX-specific implementation that is unique or different from the DEC Standard 032 implementation 
3 = Not implemented internally; converted to I/O space read or write and passed to system environment 


subclass is one of: 


1 = Processed as appropriate by Ebox microcode 


2 = Converted to Mbox IPR number and processed via internal IPR command 
3 = Processed by internal IPR command, then converted to I/O space read or write and passed to system environment 


4 = If virtual machine option is implemented, processed as in 1; otherwise, as in 3 


5 = Processed by internal IPR command 


6 = May be block decoded; reference causes UNDEFINED behavior 


7 = Full interval timer may be implemented in the system environment. Subset ICCS is implemented in NVAX CPU 


chip 
8 = Converted to MFVP MSYNC 


(continued on next page) 
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Central Processor 
3.1 Processor State 


Table 3-4 (Cont.) Processor Registers 


Number 

Register Name Mnemonic (Dec) (Hex) Type ImpI Cat l/O Address 
Reserved - 44 2C - - 3 E10000BO 
Reserved - 45 2D - - 3 E10000B4 
Reserved - 46 2E - - 3 E10000B8 
Reserved - 47 2F - - 3 E10000BC 
Reserved - 48 30 - - 3 E10000C0 
Reserved - 49 31 - - 3 E10000C4 
Reserved - 50 32) «(- - 3 E10000C8 
Reserved - 51 33 = - - 3 E10000CC 
Reserved - 52 34 - - 3 E10000D0 
Reserved - 538 385 - 3 E10000D4 
Reserved - 54 386— | - 3 E10000D8 
I/O System Reset Register IORESET 55 37 W SSC 2-3 E10000DC 
Memory Management Enable’ MAPEN 56 38 RW NVAX 1-2 - 
Translation Buffer Invalidate All? TBIA 57 39 OW NVAX 1-1 - 
Translation Buffer Invalidate Single? TBIS 58 3A W  NVAX 1-1 - 
Reserved - 59 3B - - 3 E10000EC 
Reserved - 60 3C - - 3 E10000F0 


lnitialized on reset 


3Change broadcast to vector unit if present 


Type: 

R = Read-only register 

RW = Read/write register 

W = Write-only register 
Impl(emented): 

NVAX = Implemented in the NVAX CPU chip 

System = Implemented in the system environment 

Vector = Implemented in the optional vector unit or its NDAL interface 
Cat(egory), class-subclass, where: 


class is one of: 


1 = Implemented per DEC Standard 032 


2 = NVAX-specific implementation that is unique or different from the DEC Standard 032 implementation 
3 = Not implemented internally; converted to I/O space read or write and passed to system environment 


subclass is one of: 


1 = Processed as appropriate by Ebox microcode 
2 = Converted to Mbox IPR number and processed via internal IPR command 


3 = Processed by internal IPR command, then converted to I/O space read or write and passed to system environment 


4 = If virtual machine option is implemented, processed as in 1; otherwise, as in 3 
5 = Processed by internal IPR command 
6 = May be block decoded; reference causes UNDEFINED behavior 


7 = Full interval timer may be implemented in the system environment. Subset ICCS is implemented in NVAX CPU 


chip 
8 = Converted to MFVP MSYNC 
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Central Processor 
3.1 Processor State 


Table 3-4 (Cont.) Processor Registers 


Number 

Register Name Mnemonic (Dec) (Hex) Type Impl Cat 1/O Address 
System Identification SID 62 38E R NVAX 1-1 - 
Translation Buffer Check TBCHK 63 3F W NVAX 1-1 - 

IPL 14 Interrupt ACK? IAK14 64 40 R SSC 2-3 E1000100 
IPL 15 Interrupt ACK? IAK15 65 41 R SSC 2-3 E1000104 
IPL 16 Interrupt ACK? IAK16 66 42 R SSC 2-3 E1000108 
IPL 17 Interrupt ACK® IAK17 67 43 R SSC 2-3 E100010C 
Clear Write Buffer? CWB 68 44 RW SSC) 2-3 E1000110 
Reserved - 69 45 — - 3 E1000114 
Reserved - 70 46 — - 3 E1000118 
Reserved - 71 47 - - 3 E100011C 


Testability and diagnostic use only; not for software use in normal operation 


Type: 


R = Read-only register 
RW = Read/write register 
W = Write-only register 


Impl(emented): 


NVAX = Implemented in the NVAX CPU chip 
System = Implemented in the system environment 
Vector = Implemented in the optional vector unit or its NDAL interface 


Cat(egory), class-subclass, where: 


class is one of: 


1 = Implemented per DEC Standard 032 
2 = NVAX-specific implementation that is unique or different from the DEC Standard 032 implementation 
3 = Not implemented internally; converted to I/O space read or write and passed to system environment 


subclass is one of: 


1 = Processed as appropriate by Ebox microcode 

2 = Converted to Mbox IPR number and processed via internal IPR command 

3 = Processed by internal IPR command, then converted to I/O space read or write and passed to system environment 
4 = If virtual machine option is implemented, processed as in 1; otherwise, as in 3 

5 = Processed by internal IPR command 

6 = May be block decoded; reference causes UNDEFINED behavior 

te Full interval timer may be implemented in the system environment. Subset ICCS is implemented in NVAX CPU 
chip 

8 = Converted to MFVP MSYNC 
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Table 3-4 (Cont.) Processor Registers 


Register Name 


Mnemonic (Dec) (Hex) Type Impl 


Number 


Cat l/O Address 


Reserved - 72 48 — - 3 E1000120 
Reserved - 73 49 — - 3 E1000124 
Reserved - 74 4A — - 3 E1000128 
Reserved - 75 4B - - 3 E100012C 
Reserved - 76 4C — - 3 E1000130 
Reserved - 77 4D -—- - 3 E1000134 
Reserved - 78 4E - - 3 E1000138 
Reserved - 79 4F - - 3 E100013C 
Reserved - 80 50 - - 3 E1000140 
Reserved - 81 51 - - 3 E1000144 
Reserved - 82 52 —- - 3 E1000148 
Reserved - 83 53 - - 3 E100014C 
Reserved - 84 54 —- - 3 E1000150 
Reserved - 8 55 —- - 3 E1000154 
Type: 


R = Read-only register 
RW = Read/write register 
W = Write-only register 


Imp](emented): 


NVAX = Implemented in the NVAX CPU chip 
System = Implemented in the system environment 


Vector = Implemented in the optional vector unit or its NDAL interface 


Cat(egory), class-subclass, where: 


class is one of: 


1 = Implemented per DEC Standard 032 


2 = NVAX-specific implementation that is unique or different from the DEC Standard 032 implementation 
3 = Not implemented internally; converted to I/O space read or write and passed to system environment 


subclass is one of: 


1 = Processed as appropriate by Ebox microcode 


2 = Converted to Mbox IPR number and processed via internal IPR command 
3 = Processed by internal IPR command, then converted to I/O space read or write and passed to system environment 


4 = If virtual machine option is implemented, processed as in 1; otherwise, as in 3 


5 = Processed by internal IPR command 


6 = May be block decoded; reference causes UNDEFINED behavior 


7 = Full interval timer may be implemented in the system environment. Subset ICCS is implemented in NVAX CPU 


chip 
8 = Converted to MFVP MSYNC 
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Table 3-4 (Cont.) Processor Registers 


Central Processor 


3.1 Processor State 


Register Name 


Mnemonic (Dec) (Hex) Type Impl 


Number 


Cat l/O Address 


Reserved - 86 56 - - 3 E1000158 
Reserved - 87 57 = - 3 E100015C 
Reserved - 88 58 —- - 3 E1000160 
Reserved - 89 59 - - 3 E1000164 
Reserved - 90 5A - - 3 E1000168 
Reserved - 91 5B - - 3 E100016C 
Reserved - 92 5C - - 3 E1000170 
Reserved - 93 5D - - 3 E1000174 
Reserved - 94 5E - - 3 E1000178 
Reserved - 95 5F - - 3 E100017C 
Reserved - 96 60 - - 3 E1000180 
Reserved - 97 61 - - 3 E1000184 
Reserved - 98 62 - - 3 E1000188 
Reserved - 99 63 - - 3 E100018C 
Type: 


R = Read-only register 
RW = Read/write register 
W = Write-only register 


Imp](emented): 


NVAX = Implemented in the NVAX CPU chip 
System = Implemented in the system environment 


Vector = Implemented in the optional vector unit or its NDAL interface 


Cat(egory), class-subclass, where: 


class is one of: 


1 = Implemented per DEC Standard 032 


2 = NVAX-specific implementation that is unique or different from the DEC Standard 032 implementation 
3 = Not implemented internally; converted to I/O space read or write and passed to system environment 


subclass is one of: 


1 = Processed as appropriate by Ebox microcode 


2 = Converted to Mbox IPR number and processed via internal IPR command 
3 = Processed by internal IPR command, then converted to I/O space read or write and passed to system environment 


4 = If virtual machine option is implemented, processed as in 1; otherwise, as in 3 


5 = Processed by internal IPR command 


6 = May be block decoded; reference causes UNDEFINED behavior 


7 = Full interval timer may be implemented in the system environment. Subset ICCS is implemented in NVAX CPU 


chip 
8 = Converted to MFVP MSYNC 
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Central Processor 
3.1 Processor State 


Table 3-4 (Cont.) Processor Registers 


Register Name 


Mnemonic (Dec) (Hex) Type Impl 


Number 


Cat l/O Address 


Reserved for VM - 100 64 - - 3 E1000190 
Reserved for VM - 101 65 - - 3 E1000194 
Reserved for VM - 102 66 - - 3 E1000198 
Reserved - 103 67) - - 3 E100019C 
Reserved - 104. 68 - - 3 E10001A0 
Reserved - 105 69 -— - 3 E10001A4 
Reserved - 106 6A -— - 3 E10001A8 
Reserved - 107 6B - - 3 E10001AC 
Reserved - 108 6C —- - 3 E10001B0 
Reserved - 109 6D - - 3 E10001B4 
Reserved - 110 6E - - 3 E10001B8 
Reserved - 111 6F - - 3 E10001BC 
Reserved - 112 70 - - 3 E10001C0 
Reserved - 118 71 - - 3 E10001C4 
Reserved - 114.72 - - 3 E10001C8 
Reserved - 115 73 - - 3 E10001CC 
Reserved - 116 74 - - 3 E10001D0 
Reserved - 117 7 -—- - 3 E10001D4 
Type: 


R = Read-only register 
RW = Read/write register 
W = Write-only register 


Impl(emented): 


NVAX = Implemented in the NVAX CPU chip 
System = Implemented in the system environment 


Vector = Implemented in the optional vector unit or its NDAL interface 


Cat(egory), class-subclass, where: 


class is one of: 


1 = Implemented per DEC Standard 032 


2 = NVAX-specific implementation that is unique or different from the DEC Standard 032 implementation 
3 = Not implemented internally; converted to I/O space read or write and passed to system environment 


subclass is one of: 


1 = Processed as appropriate by Ebox microcode 


2 = Converted to Mbox IPR number and processed via internal IPR command 
3 = Processed by internal IPR command, then converted to I/O space read or write and passed to system environment 


4 = If virtual machine option is implemented, processed as in 1; otherwise, as in 3 


5 = Processed by internal IPR command 


6 = May be block decoded; reference causes UNDEFINED behavior 
7 = Full interval timer may be implemented in the system environment. Subset ICCS is implemented in NVAX CPU 


chip 
8 = Converted to MFVP MSYNC 
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Central Processor 
3.1 Processor State 


Table 3-4 (Cont.) Processor Registers 


Number 

Register Name Mnemonic (Dec) (Hex) Type Impl Cat l/O Address 
Reserved - 118 76 —- - 3 E10001D8 
Reserved - 119 77) - - 3 E10001DC 
Reserved - 120 78 —- - 3 E10001E0 
Reserved - 121 79 - - 3 E10001E4 
Interrupt System Status Register INTSYS 122 7A RW NVAX 2-1 - 
Performance Monitoring Facility Count PMFCNT 123 7B RW NVAX 2-1 - 
Patchable Control Store Control Register PCSCR 124 7C€C WO NVAX 2-1 - 

Ebox Control Register ECR 125 7D RW NVAX 2-1 - 

Mbox TB Tag Fill? MTBTAG 126 7E W  NVAX 2-1 - 

Mbox TB PTE Fill? MTBPTE 127 7F W  NVAX 2-1 - 

Chox Control Register CCTL 160 AO RW NVAX 2-5 - 
Reserved - 161 Al -— NVAX 2-6 - 

Bcache Data ECC BCDECC 162 A2 W  NVAX 2-5 - 

Bceache Error Tag Status BCETSTS 1638 A3 RW NVAX 2-5 - 

Bcache Error Tag Index BCETIDX 164 A4 R NVAX 2-5 - 


Testability and diagnostic use only; not for software use in normal operation 


Type: 


R = Read-only register 
RW = Read/write register 
W = Write-only register 


Impl(emented): 


NVAX = Implemented in the NVAX CPU chip 
System = Implemented in the system environment 
Vector = Implemented in the optional vector unit or its NDAL interface 


Cat(egory), class-subclass, where: 


class is one of: 


1 = Implemented per DEC Standard 032 
2 = NVAX-specific implementation that is unique or different from the DEC Standard 032 implementation 
3 = Not implemented internally; converted to I/O space read or write and passed to system environment 


subclass is one of: 


1 = Processed as appropriate by Ebox microcode 

2 = Converted to Mbox IPR number and processed via internal IPR command 

3 = Processed by internal IPR command, then converted to I/O space read or write and passed to system environment 
4 = If virtual machine option is implemented, processed as in 1; otherwise, as in 3 

5 = Processed by internal IPR command 

6 = May be block decoded; reference causes UNDEFINED behavior 

ce Full interval timer may be implemented in the system environment. Subset ICCS is implemented in NVAX CPU 
chip 

8 = Converted to MFVP MSYNC 
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Central Processor 
3.1 Processor State 


Table 3-4 (Cont.) Processor Registers 


Register Name 


Number 
Mnemonic (Dec) (Hex) Type Impl 


Cat l/O Address 


Beache Error Tag 

Bceache Error Data Status 
Bcache Error Data Index 
Bcache Error ECC 

Reserved 

Reserved 

Fill Error Address 

Fill Error Status 

Reserved 

NDAL Error Status 
Reserved 

NDAL Error Output Address 
Reserved 

NDAL Error Output Command 


Reserved 


BCETAG 165 
BCEDSTS 166 
BCEDIDX 167 


BCEDECC 168 
- 169 
- 170 
CEFADR 171 
CEFSTS 172 
- 173 
NESTS = 174 
- 175 
NEOADR 176 
- 177 
NEOCMD 178 
- 179 


A5 
A6 
A7 


R 
RW 
R 
R 


NVAX 
NVAX 


Type: 
R = Read-only register 
RW = Read/write register 
W = Write-only register 


Imp](emented): 


NVAX = Implemented in the NVAX CPU chip 


System = Implemented in the system environment 
Vector = Implemented in the optional vector unit or its NDAL interface 


Cat(egory), class-subclass, where: 


class is one of: 


1 = Implemented per DEC Standard 032 


2 = NVAX-specific implementation that is unique or different from the DEC Standard 032 implementation 
3 = Not implemented internally; converted to I/O space read or write and passed to system environment 


subclass is one of: 


1 = Processed as appropriate by Ebox microcode 


2 = Converted to Mbox IPR number and processed via internal IPR command 
3 = Processed by internal IPR command, then converted to I/O space read or write and passed to system environment 


4 = If virtual machine option is implemented, processed as in 1; otherwise, as in 3 
5 = Processed by internal IPR command 


6 = May be block decoded; reference causes UNDEFINED behavior 
7 = Full interval timer may be implemented in the system environment. Subset ICCS is implemented in NVAX CPU 


chip 
8 = Converted to MFVP MSYNC 
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Table 3-4 (Cont.) Processor Registers 


3 


Central Processor 


.1 Processor State 


Register Name 


Number 
Mnemonic (Dec) (Hex) Type Impl 


Cat l/O Address 


NDAL Error Data High NEDATHI 180 B4 NVAX 2-5 - 
Reserved - 181 Bd NVAX 2-6 - 

NDAL Error Data Low NEDATLO182_ B6 NVAX 2-5 - 
Reserved - 183 B7 NVAX 2-6 - 

NDAL Error Input Command NEICMD 184 B8 NVAX 2-5 - 
Reserved - 185 B9 NVAX 2-6 - 
Reserved - 186 BA NVAX 2-6 - 
Reserved - 187 BB NVAX 2-6 - 
Reserved - 188 BC NVAX 2-6 - 
Reserved - 189 BD NVAX 2-6 - 
Reserved - 190 BE NVAX 2-6 - 
Reserved - 191 BF NVAX 2-6 - 
Reserved - 192 CO - 3 E1000300 
Reserved - 193 Cl - 3 E1000304 
Reserved - 194 C2 - 3 E1000308 
Reserved - 195 C3 - 3 E100030C 
Type: 


R = Read-only register 

RW = Read/write register 

W = Write-only register 
Imp](emented): 


NVAX = Implemented in the NVAX CPU chip 


System = Implemented in the system environment 


Vector = Implemented in the optional vector unit or its NDAL interface 


Cat(egory), class-subclass, where: 


class is one of: 


1 = Implemented per DEC Standard 032 


2 = NVAX-specific implementation that is unique or different from the DEC Standard 032 implementation 
3 = Not implemented internally; converted to I/O space read or write and passed to system environment 


subclass is one of: 


1 = Processed as appropriate by Ebox microcode 
2 = Converted to Mbox IPR number and processed via internal IPR command 


3 = Processed by internal IPR command, then converted to I/O space read or write and passed to system environment 


4 = If virtual machine option is implemented, processed as in 1; otherwise, as in 3 


5 = Processed by internal IPR command 


6 = May be block decoded; reference causes UNDEFINED behavior 
7 = Full interval timer may be implemented in the system environment. Subset ICCS is implemented in NVAX CPU 


chip 
8 = Converted to MFVP MSYNC 


(continued on next page) 
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Table 3-4 (Cont.) Processor Registers 


Number 

Register Name Mnemonic (Dec) (Hex) Type ImpI Cat l/O Address 
Reserved - 196 C4 - - 3 E1000310 
Reserved - 197 C5 - - 3 E1000314 
Reserved - 198 C6 —- - 3 E1000318 
Reserved - 199 C7 - - 3 E100031C 
Reserved - 200 C8 - - 3 E1000320 
Reserved - 201 C9 - - 3 E1000324 
Reserved - 202 CA - - 3 E1000328 
Reserved - 203 CB - - 3 E100032C 
Reserved - 204 CC - - 3 E1000330 
Reserved - 205 CD - - 3 E1000334 
Reserved - 206 CE - - 3 E1000338 
Reserved - 207 CF - - 3 E100033C 
VIC Memory Address Register VMAR 208 DO RW NVAX 2-5 - 

VIC Tag Register VTAG 209 Dil RW NVAX 2-5 - 

VIC Data Register VDATA 210 D2 RW NVAX 2-5 - 

Ibox Control and Status Register ICSR 211 D3 RW NVAX 2-5 - 


Type: 


R = Read-only register 
RW = Read/write register 
W = Write-only register 


Imp](emented): 


NVAX = Implemented in the NVAX CPU chip 
System = Implemented in the system environment 
Vector = Implemented in the optional vector unit or its NDAL interface 


Cat(egory), class-subclass, where: 


class is one of: 


1 = Implemented per DEC Standard 032 
2 = NVAX-specific implementation that is unique or different from the DEC Standard 032 implementation 
3 = Not implemented internally; converted to I/O space read or write and passed to system environment 


subclass is one of: 


1 = Processed as appropriate by Ebox microcode 

2 = Converted to Mbox IPR number and processed via internal IPR command 

3 = Processed by internal IPR command, then converted to I/O space read or write and passed to system environment 
4 = If virtual machine option is implemented, processed as in 1; otherwise, as in 3 

5 = Processed by internal IPR command 

6 = May be block decoded; reference causes UNDEFINED behavior 

ie Full interval timer may be implemented in the system environment. Subset ICCS is implemented in NVAX CPU 
chip 

8 = Converted to MFVP MSYNC 


(continued on next page) 
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Table 3-4 (Cont.) Processor Registers 


Number 
Register Name Mnemonic (Dec) (Hex) Type ImpI Cat l/O Address 
Ibox Branch Prediction Control Register® BPCR 212 D4 RW NVAX 2-5 - 
Reserved - 213 D5 - NVAX 2-6 - 
Ibox Backup PC® BPC 214 D6 R  NVAX 2-5 = 
Ibox Backup PC with RLOG Unwind® BPCUNW 215 D7 R NVAX 2-5 - 
Reserved - 216 D8& - NVAX 2-6 - 
Reserved - 217 D9 - NVAX 2-6 - 
Reserved - 218 DA -— NVAX 2-6 - 
Reserved - 219 DB - NVAX 2-6 - 
Reserved - 220 DC - NVAX 2-6 - 
Reserved - 221 DD - NVAX 2-6 - 
Reserved - 222 DE - NVAX 2-6 - 
Reserved - 223 DF - NVAX 2-6 - 


Testability and diagnostic use only; not for software use in normal operation 


Type: 


R = Read-only register 
RW = Read/write register 
W = Write-only register 


Imp](emented): 


NVAX = Implemented in the NVAX CPU chip 
System = Implemented in the system environment 
Vector = Implemented in the optional vector unit or its NDAL interface 


Cat(egory), class-subclass, where: 


class is one of: 


1 = Implemented per DEC Standard 032 
2 = NVAX-specific implementation that is unique or different from the DEC Standard 032 implementation 
3 = Not implemented internally; converted to I/O space read or write and passed to system environment 


subclass is one of: 


1 = Processed as appropriate by Ebox microcode 

2 = Converted to Mbox IPR number and processed via internal IPR command 

3 = Processed by internal IPR command, then converted to I/O space read or write and passed to system environment 
4 = If virtual machine option is implemented, processed as in 1; otherwise, as in 3 

5 = Processed by internal IPR command 

6 = May be block decoded; reference causes UNDEFINED behavior 

ie Full interval timer may be implemented in the system environment. Subset ICCS is implemented in NVAX CPU 
chip 

8 = Converted to MFVP MSYNC 


(continued on next page) 
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Table 3-4 (Cont.) Processor Registers 


Register Name 


Number 
Mnemonic (Dec) (Hex) Type Impl 


Cat l/O Address 


Mbox PO Base Register® 

Mbox PO Length Register? 
Mbox P1 Base Register® 

Mbox P1 Length Register? 
Mbox System Base Register? 
Mbox System Length Register? 
Mbox Memory Management Enable® 
Mbox Physical Address Mode 
Mbox MME Address 

Mbox MME PTE Address 
Mbox MME Status 


MPOBR 
MPOLR 
MP1BR 
MP1LR 
MSBR 
MSLR 


224 
225 
226 
227 
228 
229 


MMAPEN 230 
PAMODE 231 
MMEADR 232 
MMEPTE 233 
MMESTS 234 


EO 
E1 
E2 
E3 
E4 
E5 
E6 
E7 
E8 
E9 
EA 


RW 
RW 
RW 
RW 
RW 


NVAX 
NVAX 
NVAX 
NVAX 
NVAX 
NVAX 
NVAX 
NVAX 
NVAX 
NVAX 
NVAX 


a 
Boe 
5 = 
25 ok 
7 a 
2. 
25 Ss 
rs a 
5 = 
aoe = 


Testability and diagnostic use only; not for software use in normal operation 


Type: 
R = Read-only register 
RW = Read/write register 
W = Write-only register 
Imp](emented): 


NVAX = Implemented in the NVAX CPU chip 


System = Implemented in the system environment 
Vector = Implemented in the optional vector unit or its NDAL interface 


Cat(egory), class-subclass, where: 


class is one of: 


1 = Implemented per DEC Standard 032 


2 = NVAX-specific implementation that is unique or different from the DEC Standard 032 implementation 
3 = Not implemented internally; converted to I/O space read or write and passed to system environment 


subclass is one of: 


1 = Processed as appropriate by Ebox microcode 


2 = Converted to Mbox IPR number and processed via internal IPR command 
3 = Processed by internal IPR command, then converted to I/O space read or write and passed to system environment 


4 = If virtual machine option is implemented, processed as in 1; otherwise, as in 3 


5 = Processed by internal IPR command 


6 = May be block decoded; reference causes UNDEFINED behavior 
7 = Full interval timer may be implemented in the system environment. Subset ICCS is implemented in NVAX CPU 


chip 
8 = Converted to MFVP MSYNC 
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(continued on next page) 


Table 3-4 (Cont.) Processor Registers 


Central Processor 
3.1 Processor State 


Number 

Register Name Mnemonic (Dec) (Hex) Type ImpI Cat l/O Address 
Reserved - 235 EB - NVAX 2-6 - 
Mbox TB Parity Address TBADR 236 EC R NVAX 2-5 - 
Mbox TB Parity Status TBSTS 237 ED RW NVAX 2-5 - 
Reserved - 238 EE - NVAX 2-6 - 
Reserved - 239 EF - NVAX 2-6 — 
Reserved - 240 FO - NVAX 2-6 - 
Reserved - 241 Fl - NVAX 2-6 - 
Mbox Pcache Parity Address PCADR 242 F2 R NVAX 2-5 - 
Reserved - 243 F3 - NVAX 2-6 - 
Mbox Pcache Status PCSTS 244 F4 RW NVAX 2-5 - 
Reserved - 245 F5 - NVAX 2-6 - 
Type: 


R = Read-only register 

RW = Read/write register 

W = Write-only register 
Imp](emented): 


NVAX = Implemented in the NVAX CPU chip 


System = Implemented in the system environment 
Vector = Implemented in the optional vector unit or its NDAL interface 


Cat(egory), class-subclass, where: 


class is one of: 


1 = Implemented per DEC Standard 032 


2 = NVAX-specific implementation that is unique or different from the DEC Standard 032 implementation 
3 = Not implemented internally; converted to I/O space read or write and passed to system environment 


subclass is one of: 


1 = Processed as appropriate by Ebox microcode 


2 = Converted to Mbox IPR number and processed via internal IPR command 
3 = Processed by internal IPR command, then converted to I/O space read or write and passed to system environment 


4 = If virtual machine option is implemented, processed as in 1; otherwise, as in 3 


5 = Processed by internal IPR command 


6 = May be block decoded; reference causes UNDEFINED behavior 
7 = Full interval timer may be implemented in the system environment. Subset ICCS is implemented in NVAX CPU 


chip 
8 = Converted to MFVP MSYNC 


(continued on next page) 
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3.1 Processor State 


Table 3-4 (Cont.) Processor Registers 


Number 

Register Name Mnemonic (Dec) (Hex) Type ImpI Cat I/O Address 
Reserved - 246 FE - NVAX 2-6 - 
Reserved - 247 FT - NVAX 2-6 - 
Mbox Pcache Control PCCTL 248 F8 RW NVAX 2-5 - 
Reserved - 249 FO - NVAX 2-6 - 
Reserved - 250 FA - NVAX 2-6 — 
Reserved - 251 FB - NVAX 2-6 - 
Reserved - 252 FC - NVAX 2-6 - 
Reserved - 253 FD - NVAX 2-6 - 
Reserved - 254 FE - NVAX 2-6 - 
Reserved - 255 FF - NVAX 2-6 - 
Unimplemented - - 100- - 3 — 

OOFFFFFF 
See Table 3-3 - - 01000000— — 2 - 

FFFFFFFF 


Type: 


R = Read-only register 
RW = Read/write register 
W = Write-only register 


Impl(emented): 


NVAX = Implemented in the NVAX CPU chip 
System = Implemented in the system environment 
Vector = Implemented in the optional vector unit or its NDAL interface 


Cat(egory), class-subclass, where: 


class is one of: 


1 = Implemented per DEC Standard 032 
2 = NVAX-specific implementation that is unique or different from the DEC Standard 032 implementation 
3 = Not implemented internally; converted to I/O space read or write and passed to system environment 


subclass is one of: 


1 = Processed as appropriate by Ebox microcode 

2 = Converted to Mbox IPR number and processed via internal IPR command 

3 = Processed by internal IPR command, then converted to I/O space read or write and passed to system environment 
4 = If virtual machine option is implemented, processed as in 1; otherwise, as in 3 

5 = Processed by internal IPR command 

6 = May be block decoded; reference causes UNDEFINED behavior 

Re Full interval timer may be implemented in the system environment. Subset ICCS is implemented in NVAX CPU 
chip 

8 = Converted to MFVP MSYNC 
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Central Processor 
3.2 Process Structure 


A process is a single thread of execution. The context of the current process is 
contained in the process control block (PCB), which is pointed to by the process 
control block base register (PCBB). The KA680 implements these structures as 
defined in VAX Architecture Reference Manual, which should be referenced for a 
description of the PCB and the PCBB. 


3.3 Data Types 


The KA680 CPU supports the following subset of the VAX data types: The central 
processor provides the following subset of the VAX data types: 


e Byte 
e Quadword 


e F-floating 


e Word 
e Character string 


e G-floating 


e Longword 
e Variable-length bit field 
e D-floating 


Support for the remaining VAX data types can be provided via macrocode 


emulation. 


3.4 Instruction Set 


The KA680 CPU implements the following subset of the VAX instruction set types 


in microcode. 


e Integer arithmetic and logical 
e Variable length bit field 

e Procedure call 

e Operating system support 

e G_floating 


e Queue 


e Address 

e Control 

e Miscellaneous 

e F floating 

e D floating 
eCharacter string 
MOVC3 

MOVC5 

CMPC3 (See Note) 
CMPC5 (See Note) 
LOCC (See Note) 
SCANC (See Note) 


SKPC (See Note) 
SPANC (See Note) 


Note 


* These instructions were in the microcode-assisted category on the 
KA630-A (MicroVAX II), and therefore had to be emulated. 
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The NVAX CPU provides special microcode assistance to aid the macrocode 
emulation of the following instruction groups: 


¢ Decimal string 
¢ CRC 
¢ EDITPC 


The following instruction groups are not implemented, but may be emulated by 
macrocode: 


¢ Octaword 
¢ Compatibility mode instructions 


Appendix H lists the entire KA680 instruction set, indicating which instructions 
have microcode assists to speed up macrocode emulation. 


3.5 Memory Management 


The KA680 implements full VAX Memory Management as defined in the VAX 
Architecture Reference Manual. System space addresses are virtually mapped 
through single-level page tables, and process space addresses are virtually 
mapped through two-level page tables. See the VAX Architecture Reference 
Manual for descriptions of the virtual-to-physical address translation process, and 
the format for VAX page table entries (PTEs). 


3.5.1. Translation Buffer 


To reduce the overhead associated with translating virtual addresses to physical 
addresses, the NVAX CPU chip employs a 96-entry, fully associative, translation 
buffer (TB) for caching VAX PTEs. Each entry can store a PTE for translating 
virtual addresses in either the VAX process space, or VAX system space. The 
translation buffer is flushed whenever the following actions are performed: 


¢ Memory management is enabled or disabled [for example, by writes to IPR 56 
(MAPEN)]. 


e Any page table base or length registers are modified (for example, by writes 
to IPRs 8 to 138). 


¢ Writing to IPR 57 (TBIA). 
In addition, individual TB entries may be flushed by writing to IPR 58 (TBIS). 


Each entry in the translation buffer is divided into two parts: a 24-bit tag 
register and a 27-bit PTE register. The tag register is used to store the virtual 
page number (VPN) of the virtual page that the corresponding PTE register 
maps, and a valid bit (TB.V) indicating that the tag contains a valid VPN. The 
PTE register stores the 21-bit PFN field, the PTE.V bit, the PTE.M bit, and the 
4-bit PROT field from the corresponding VAX PTE. 


When MAPEN bit is set in the MAPEN IPR (IPR 56), memory management 
is enabled and the CPU will perform VAX memory translation from virtual 
addresses to physical addresses. The translation buffer is the mechanism by 
which the NVAX performs quick virtual-to-physical address translations. 
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Figure 3-4 shows the format of a page table entry and a TB entry. 
Figure 3-4 PTE and TB Format 


Page Table Entry 


31 30 27 26 25 24 00 


Physical Page Frame Address 


Where: V = Valid Bit 
Prot = Authorized Access Modes 
M=_ Modify Bit 
S= _ Reserved Bit 


TB Entry 


54 53 5251 29 28 25 24 23 22 00 


TBV ~ BF 
TP 


TP = Even Tag Parity Bit 

TP_BAR = Compement of TP 

Tag = Virtual Address<31:9> 

Prot = Authorized Access Modes 

M= Modify Bit 

DP = Even Parity for Validated PTE Field 
PFN = Physical Page Frame Address 


LJ-01247-Tl0 


Note that the TB entry stores all but three bits of the PTE field. The TB entry 
does not store the S bit because it is not used, and the TB entry does not store the 
upper two bits of the PTE PFN because these bits correspond to a larger physical 
address space than NVAX CPU uses. The tag field stores the virtual page frame 
address. The TBV bit indicates whether the corresponding entry is valid. If TBV 
is set, then PTE<31> is valid because the TB only caches PTEs whose valid bits 
are set. 


During virtual-to-physical address translation, the contents of the 96 tag registers 
are compared with the virtual page number field (bits <31:9>) of the virtual 
address of the reference. If there is a match with one of the tag registers, and the 
TB.V bit indicates the entry is valid, then a translation buffer "hit" has occurred, 
and the contents of the corresponding PTE register are used for the translation. 
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If there is no match, the translation buffer does not contain the necessary VAX 
PTE information to translate the address of the reference, and the PTE must be 
fetched from memory. Upon fetching the PTE, the translation buffer is updated so 
that subsequent references to the same page of memory will hit in the translation 
buffer. 


TB entries are allocated using an NLU (not-last-used) TB allocation pointer. 

The update is achieved by replacing the entry that is selected by the replacement 
pointer. The allocation pointer increments in round robin fashion whenever a new 
buffer entry is loaded, such as after a TB miss. Because the allocation pointer is 
guaranteed not to point to the last entry referenced, this scheme implements a 
not-last-used allocation scheme. 


The associativity of each TB entry is implemented by the use of comparators on 
the TBV and tag fields. When a virtual address is to be translated, each TB tag 
comparator, whose corresponding TBV bit is set, looks for a match between the 
virtual page frame address and its corresponding tag. If no comparator finds 

a match, a "TB miss" condition has occurred in that no TB entry contains a 
translation for the specified address. 


If one of the entries detects a match ("TB hit"), the PFN, PROT, and M fields of 
the corresponding TB entry are read out of the TB and are used to complete the 
address translation. 


The PROT, and M fields, which are accessed along with the PFN, are used by 
the memory management exception detection logic to determine ACV and M=0 
conditions. 


TB entries can be invalidated in the following ways: 


e An entry can be invalidated by being displaced from the TB by allocation of 
another PTE to the same TB entry. 


e An entry can be invalidated by writing to the TBIS IPR (IPR 58). If the 
specified TBIS virtual address matches a TB tag, the TBV bit corresponding 
to the matched tag is cleared. Clearing the TBV bit invalidates the TB entry. 


e All entries can be invalidated by writing to the TBIA IPR (IPR 57). This 
command resets the TBV bit of every TB entry. 


3.5.2 30-bit to 32-bit Physical Address Translations 


When PAMODEZ=0, such as is mandatory with the KA680, the NVAX system is 
configured such that only 30-bit physical addresses are processed at the program 
level. This is done in two ways. 


1. When the address translation logic receives a physical address from one of its 
reference sources, the mapping is implemented by an address sign extension 
scheme involving the upper three address bits. In this scheme, address bits 
<31:30> are forced to the state of address<29>. 


2. When the virtual/physical address tranlation logic receives a virtual address, 
virtual address translation occurs normally without any sign extension of 
the resulting physical address. This is possible because the corresponding 
sign extension function is preprocessed on the upper three bits of page frame 
address, which is written into the TB during the TB tag fill operation. 
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The following two figures show the register format of the TBTAG and TBDATA 
IPRs. These two IPRs allow software to directly access the contents of the 
translation buffer for diagnostic purposes. 


Figure 3-5 Translation Buffer Tag (TBTAG) - IPR 47 
31 09 08 00 


Virtual Page Number (Write Only) MBZ ‘TBTAG 


LJ-01248-T10 


Figure 3-6 Translation Buffer Data (TBDATA) - IPR 59 


31 30 27 26 25 21 20 00 


PTE.M (Write Only) 
PTE.PROT (Write Only) 


PTE.V (Write Only) 
LJ-01249-TI0 


Diagnostic software may use IPR 47 (TBTAG) and IPR 59 (TBDATA) to test the 
operation of the translation buffer. A write to TBTAG writes bits <31:9> of the 
source data into the VPN field of the current tag location and clears the TB.V bit. 
A subsequent write to TBDATA interprets the source data as a PTE and writes 
PTE.V, PTE.M, PTE.PROT, and PTE.PFN into the current PTE location, sets the 
TB.V bit, and increments the NLU pointer. 


These registers are provided for diagnostic purposes only and should not be 
written during normal operation. Writes to these registers must be done under 
very controlled conditions to achieve the desired results. Specifically, the following 
restrictions apply: 


¢ The NLU pointer must be in a known state. A TBIA will initialize the NLU 
pointer to the first location in the array. 


¢ Memory management must be enabled during the use of TBTAG and 
TBDATA because writing to MAPEN implicitly does a TBIA and resets 
the NLU pointer. 


¢ Data-stream and instruction-stream references during the use of TBTAG and 
TBDATA must not be allowed to change the NLU pointer. 
Note 


The TBIS, TBIA, TBCHK, TBTAG, and TBDATA IPRs are write-only. 
An MFPR instruction used to read any of these registers will cause the 
NVAX CPU to initiate a reserved operand fault. 
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3.5.3 Memory Management Control Registers 


There are four IPRs that control the memory management unit (MMU): 


IPR 56 (MAPEN) 
IPR 57 (TBIA) 
IPR 58 (TBIS) 
IPR 63 (TBCHK) 


Memory management can be enabled/disabled via IPR 56 (MAPEN). Writing 

0 to this register with an MTPR instruction disables memory management 

and writing a 1 to this register with an MTPR instruction enables memory 
management. Writes to this register flush the translation buffer. To determine 
whether or not memory management is enabled, IPR 56 is read using the MFPR 
instruction. 


Translation buffer entries that map a particular virtual address can be 
invalidated by writing the virtual address to IPR 58 (TBIS) using the MTPR 
instruction. 


Note 


Whenever software changes a valid page table entry for the system or 
current process region, or a system page table entry that maps any part 
of the current process page table, all process pages mapped by the page 
table entry must be invalidated in the translation buffer. 


The entire translation buffer can be invalidated by writing a 0 to IPR 57 (TBIA) 
using the MTPR instruction. 


The translation buffer can be checked to see if it contains a valid translation for 
a particular virtual page by writing a virtual address within that page to IPR 63 
(TBCHK) using the MTPR instruction. If the translation buffer contains a valid 
translation for the page, the condition code V bit (bit<1> of the PSL) is set. 


Note 


The TBIS, TBIA, and TBCHK IPRs are write-only. The operation of an 
MFPR instruction from any of these registers is UNDEFINED. 


There are three pairs of base and length registers that specify the base and 
length of PO, P1, and SO space: 


e IPR 8(POBR) and IPR 9(POLR) 
e IPR 10(P1BR) and IPR 11(P1LR) 
e IPR 12(SBR) and IPR 13(SLR) 


The base and length of the PO, P1, and SO page tables may be changed by writing 
the appropriate address or length to any of the following registers: 


IPR 8 (POBR) 
IPR 9 (POLR) 
IPR 10 (P1BR) 
IPR 11 (P1LR) 
IPR 12 (SBR) 
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IPR 13 (SLR) 


Whenever the location or size of the system map is changed by changing the SBR 
(IPR 12) or SLR (IPR 13), the entire translation buffer must be cleared. The 
NVAX CPU accomplishes this by flushing the TB on any change to SBR, SLR, or 
POBR, P1BR, POLR, and P1LR. 


When a process context is loaded with the LDPCTX instruction, all TB entries 
that map process-space pages are automatically cleared. System-space mappings 
are preserved. 


There are two IPRs that are used by diagnostic software to test the translation 
buffer: 


IPR 47 (TBTAG) Format shown in Figure 3-5. 
IPR 59 (TBDATA) Format shown in Figure 3-6. 


For information regarding the use of the V, PROT, and M bit fields, consult the 
VAX Architecture Reference Manual. 


3.6 Interrupts and Exceptions 
Both interrupts and exceptions divert execution from the normal flow of control. 


An interrupt is caused by some activity outside the current process and typically 
transfers control outside the process (for example, an interrupt from an external 
hardware device). An exception is caused by the execution of the current 
instruction and is typically handled by the current process (for example, an 
arithmetic overflow). 


3.6.1 Interrupts 
Interrupts can be divided into two classes: nonmaskable and maskable. 


Nonmaskable interrupts cause a halt via the hardware halt procedure. The 
hardware halt procedure does the following: 


e Saves the PC, PSL, MAPEN<0>, and a halt code in IPRs 
e¢ Raises the processor IPL to 1F 
e Passes control to the resident firmware 


The firmware dispatches the interrupt to the appropriate service routine based 
on the halt code and hardware event indicators. Nonmaskable interrupts cannot 
be blocked by raising the processor IPL, but can be blocked by running out of the 
halt protected address space (except those nonmaskable interrupts that generate 
a halt code of 3). Nonmaskable interrupts with a halt code of 3 cannot be blocked 
because this halt code is generated after a hardware reset. 


Maskable interrupts cause the following: 
¢ The PC and PSL are saved. 


¢ The processor IPL is raised to the priority level of the interrupt (except 
for Q22—bus, mass storage, and network interface interrupts in which the 
processor IPL is set to 17, independent of the level at which the interrupt was 
received). 


¢ The interrupt is dispatched to the appropriate service routine through the 
system control block (SCB). 
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The various interrupt conditions for the KA680 are listed in Table 3-5 along with 
their associated priority levels and SCB offsets. The reader should note that this 
table is intended as a quick reference, and may not include all possible causes of 
the various interrupts, specifically with regard to error conditions. 


Table 3-5 Interrupt Priority Levels 


SCB 

Priority Level Interrupt Condition Offset 
Nonmaskable BDCOK and BPOK negated then asserted on Q22—bus (Powerup) * 

- BDCOK negated then asserted while BPOK asserted on Q22-bus _** 

(Powerup) 

- BHALT asserted on Q22—bus i 

- BREAK generated by the console device ee 

1F Unused = 

1E BPOK negated on Q22-bus 0C 

1D Backup cache addressing errors 60 


- Backup cache uncorrectable data ECC errors on Beache read fora 60 
write that hits valid/owned 


- NVAX read timeout or Read Data Error on Oread for a write after 60 
the requested quadword has arrived 


- Illegal length write transaction to memory or I/O 60 
- Reserved command detected by memory or I/O during write 60 
transaction 
- Pending write times out waiting for disown write 60 
- Disown write to unowned memory location 60 
= Main memory NXM errors on writes 60 
= NDAL parity errors on writes 60 
- CP-bus NXM/TIMEOUT on a write 60 
= Q22-bus NXM/NOSACK on a write 60 
- Q22-bus NOGRANT on a write 60 
- Uncorrectable memory errors during map read for Q22—bus 60 
address translation 
1C:1B Unused = 
1A Correctable main memory errors 54 
- Uncorrectable main memory errors 54 


* These conditions generate a hardware halt procedure with a halt code of 3 (hardware reset). 
** These conditions generate a hardware halt procedure with a halt code of 2 (external halt). 


(continued on next page) 
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Table 3-5 (Cont.) Interrupt Priority Levels 


SCB 

Priority Level Interrupt Condition Offset 

- Correctable O-bit memory errors 54 

- Pending read times out waiting for disown write 54 

- No acknowledgement on returned read data from NMC 54 

- NDAL data parity errors 54 

- Primary cache tag or data parity errors 54 

- Virtual instruction cache tag or data parity errors 54 

- Backup cache addressing errors 54 

- Backup cache correctable data ECC errors 54 

- Backup cache uncorrectable data ECC errors 54 

- Backup cache correctable tag ECC errors 54 

- Backup cache uncorrectable data ECC errors 54 

- Illegal length transaction to memory or I/O space 54 

- Reserved command to memory or I/O space 54 

- CP-bus parity errors on I/O read transactions 54 

- CP-bus ERR_L signal asserted by I/O device during I/O read 54 

transaction 

- CP Bus NXM/TIMEOUTS errors on I/O reads 54 

19:18 Unused = 

17 BR7 L asserted Q22-bus 
vector 
plus 
20016 

16 Interval timer interrupt co 

- BR6 L asserted Q22-bus 
vector 
plus 
20016 

15 BR5 L asserted Q22-bus 
vector 
plus 
20016 


* These conditions generate a hardware halt procedure with a halt code of 3 (hardware reset). 
** These conditions generate a hardware halt procedure with a halt code of 2 (external halt). 


(continued on next page) 
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Table 3-5 (Cont.) Interrupt Priority Levels 


SCB 
Priority Level Interrupt Condition Offset 
14 Console Terminal F8,FC 
- Programmable Timers 78,7C 
- Mass storage interface one (DSSI port 1)(External) 108 
- Mass storage interface two (DSSI port 2)(Internal) 104 
- Network interface 10C 
- Interprocessor doorbell 204 
- BR4 L asserted Q22-bus 
vector 
plus 
20016 
13:10 Unused - 
OF:01 Software interrupt requests 84-BC 


* These conditions generate a hardware halt procedure with a halt code of 3 (hardware reset). 
** These conditions generate a hardware halt procedure with a halt code of 2 (external halt). 


Note 


Because the Q22-bus does not allow differentiation between the four bus 
grant levels (for example, a level 7 device could respond to a level 4 bus 
grant), the KA680 CPU raises the IPL to 17 after responding to interrupts 
generated by the assertion of either BR7_L, BR6_L, BR5_L, or BR4_L. 
The KA680 maintains the IPL at the priority of the interrupt for all other 
interrupts. 


The interrupt system is controlled by three IPRs: 


¢ IPR 18, the interrupt priority level register (IPLR) (Figure 3-7), is used for 
loading the processor priority field in the PSL (bits<20:16>). 


e IPR 20, the software interrupt request register (SIRR) (Figure 3-8), is used 
for creating software interrupt requests. 


¢ IPR 21, the software interrupt summary register (SISR) (Figure 3-9), records 
pending software interrupt requests at levels 1 through 15. 


The format of these registers is presented in Figure 3-7, Figure 3-8, and 
Figure 3-9. Refer to the VAX Architecture Reference Manual for more information 
on these registers. 
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Figure 3—7 Interrupt Priority Level Register (IPLR) - IPR 18 


31 05 04 00 
Ignored, Returns 0 PSL<20:16> :IPLR 
LJ-01250-T10 
Figure 3-8 Software Interrupt Request Register (SIRR) - IPL 20 
31 04 03 00 
LJ-01251-TI0 
Figure 3-9 Software Interrupt Summary Register (SISR) - IPL 21 
31 16 15 00 
Pending Software Interrupts ‘SISR 
FEDCBAQIX8B765 43 21 ‘ 
MBZ 
LJ-01252-T10 


3.6.1.1 Power Fail Interrupt 


Power fail interrupts are requested to report imminent loss of power to the CPU. 
Power fail interrupts are requested via the PWRFL_L pin at IPL 1E (hex) and 
are dispatched to the operating system through SCB vector OC (hex). 


The stack frame for a power fail interrupt is shown in Figure 3-10. 


Figure 3-10 Power Fail Interrupt Stack Frame 


31 00 


PSL 


LJ-01317-TI0 
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3.6.1.2 Hard Error Interrupts 


Hard error interrupts are requested to report an error that was detected 
asynchronously with respect to instruction execution. This results in an interrupt 
at IPL 1D (hex) to be dispatched through SCB vector 60 (hex). Typically, these 
errors indicate that machine state has been corrupted and that retry is not 
possible. 


The stack frame for a hard error interrupt is shown in Figure 3-11. 


Figure 3-11 Hard Error Interrupt Stack Frame 


31 00 
PC (SP) 
PSL 


LJ-01317-TI0 


3.6.1.3 Soft Error Interrupts 


Soft error interrupts are requested to report errors that were detected, but did 
not affect instruction execution. This results in an interrupt at IPL 1A (hex) to be 
dispatched through SCB vector 54 (hex). 


The stack frame for a soft error interrupt is shown in Figure 3-12. 


Figure 3-12 Soft Error Interrupt Stack Frame 


31 00 
PSL 
LJ-01253-TI0 


3.7 Exceptions 


The VAX architecture recognizes six classes of exceptions. Table 3—6 lists instances of exceptions 
in each class. 


Table 3-6 Exception Classes 


Exception Class Instances 


Arithmetic traps/faults Integer overflow trap 
Integer divide-by-zero trap 
Subscript range trap 
Floating overflow fault 
Floating divide-by-zero fault 
Floating underflow fault 


(continued on next page) 


3-34 Central Processor 


Central Processor 
3.7 Exceptions 


Table 3-6 (Cont.) Exception Classes 


Exception Class Instances 


Memory management exceptions Access control violation fault 
Translation not valid fault 
M=0 fault 


Operand reference exceptions Reserved addressing mode fault 
Reserved operand fault or abort 


Instruction execution exceptions Reserved/privileged instruction fault 
Emulated instruction faults 
XFC fault 
Change-mode trap 
Breakpoint fault 
Vector disabled fault 


Tracing exceptions Trace fault 


System failure exceptions Kernel-stack-not-valid abort 
Interrupt-stack-not-valid halt 
Console error halt 
Machine check abort 


A trap is an exception occuring at the end of the instruction that caused the 
exception. Therefore, the PC saved on the stack is the address of the next 
instruction that would normally have been executed. 


A fault is an exception that occurs during an instruction. It leaves the registers 
and memory in a consistent state so that elimination of the fault condition and 
restarting the instruction will give correct results. After the instruction faults, 

the PC saved on the stack points to the instruction that faulted. 


An abort is an exception that occurs during an instruction. An abort leaves 

the value of registers and memory UNPREDICTABLE so that the instruction 
cannot necessarily be correctly restarted, completed, simulated, or undone. In 
most instances, the NVAX microcode attempts to convert an abort into a fault by 
restoring the state that was present at the start of the instruction, which caused 
the abort. 


The following sections describe only those exceptions that are unique to the 
NVAX CPU, or where the VAX Architecture Reference Manual is not clear about 
the implementation. 


3.7.1 Arithmetic Exceptions 


Arithmetic exceptions are detected during the execution of instructions that 
perform integer or floating-point arithmetic manipulations. Whether the 
exception is reported as a trap or a fault is a function of the specific event. 

In any case, the exception is reported through SCB vector 34 (hex) with the stack 
frame shown in Figure 3-13. Table 3—7 lists the exceptions reported by this 
mechanism. 
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Figure 3-13 Arithmetic Exception Stack Frame 


LJ-01254-T10 


Table 3-7 Arithmetic Exceptions 


Type Code 
Decimal Hex Type Exception 
1 1 Trap Integer overflow 
2 2 Trap Integer divide-by-zero 
7 7 Trap Subscript range 
8 8 Fault Floating overflow 
9 9 Fault Floating divide-by-zero 
10 A Fault Floating underflow 


3.7.2 Memory Management Exceptions 


Memory management exceptions are detected during a memory reference and are 
always reported as faults. The three memory management exceptions are listed 
in Table 3-8. All three exceptions push the same frame on the stack, as shown 
in Figure 3-14. The top longword of the stack frame contains a fault parameter 
whose bits are described in Table 3-9. 


Table 3-8 Memory Management Exceptions 


SCB Vector Exception 

20 (hex) Access control violation 
24 (hex) Translation not valid 
3C (hex) Modify fault 
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Figure 3-14 Memory Management Exception Stack Frame 


31 30 29 28 27 26 25 24 23 22 21 20 1918 17 16 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00 


Some Virtual Address in the Faulting Page 


LJ-01255-T10 


Table 3-9 Memory Management Exception Fault Parameter 


Bit Mnemonic Meaning 

0 L Length violation 

1 P PTE reference 

2 M Modify or write intent 
3 0 Always 0 

4 0 Always 0 


3.7.3 Emulated Instruction Exceptions 


The NVAX CPU implements the VAX base instruction group. For certain 
instructions outside that group, the NVAX microcode provides support for 
the macrocode emulation of instructions. There are two types of emulation 
exceptions, depending on whether PSL<FPD> is set at the beginning of the 
instruction. 


If PSL<FPD>=0 at the beginning of the instruction, the exception is reported 
through SCB vector C8 (hex) as a trap with the stack frame shown in 
Figure 3-15. The longwords in the stack frame are described in Table 3-10. 


Central Processor 3-37 


Central Processor 
3.7 Exceptions 


Figure 3-15 Instruction Emulation Trap Stack Frame 


(SP) 


31 00 


LJ-01256-T10 
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Table 3-10 Instruction Emulation Trap Stack Frame 


Location Use 

Opcode Zero-extended opcode of the emulated instruction. 

Old PC PC of the opcode of the emulated instruction. 

Specifiers Address of the specified operand for specifiers of access type write 


(.wx) or address (.ax). Operand value for specifiers of access type 
read (.rx). For read-type operands whose size is smaller than a 
longword, the remaining bits are UNPREDICTABLE. For those 
instructions that do not have 8 specifiers, the remaining specifier 
longwords contain UNPREDICTABLE values. 


PC PC of the instruction following the emulated instruction. 
PSL PSL saved at the time of the trap. 


If PSL<FPD>=1 at the beginning of the instruction, the exception is reported 
through SCB vector CC (hex) as a fault with the stack frame shown in 
Figure 3-16. In this case, PC is that of the opcode of the emulated instruction. 


Figure 3-16 Suspended Emulation Fault Stack Frame 


31 00 


LJ-01257-T10 


3.7.4 Vector Unit Disabled Fault 


When the NVAX CPU attempts to issue a vector instruction to the optional vector 
processor, it will result in this fault because the KA680 does not contain a vector 
unit. There are no parameters for this exception (beside the usual PC/PSL pair). 


3.7.5 Machine Check Exceptions 


A machine check exception is reported through SCB vector 04 (hex) when the 
NVAX CPU detects an error condition. The frame pushed on the stack for a 
machine check indicates the type of error and provides internal state information 
that may help identify the cause of the error. The generic machine check stack 
frame is shown in Figure 3-17. 
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Figure 3-17 Generic Machine Check Stack Frame 


31 00 
e e e 
PSL 
LJ-01258-TI0 


3.7.6 Console Halts 


In certain microcode flows, the NVAX microcode may detect an inconsistency in 
internal state, a kernel-mode HALT, or a system reset. In these instances, the 
microcode initiates a hardware restart sequence, which passes control to the 
console program. 


When a hardware restart sequence is initiated, the NVAX microcode saves the 
current CPU state, partially initializes the CPU, and passes control to the console 
program at physical address E0040000 (hex). 


During a hardware restart sequence, the stack pointer is saved in the appropriate 
stack pointer IPR (0 through 4), the current PC is saved in IPR 42 (SAVPC), and 
the current PSL, halt code, and validity flag are saved in IPR 43 (SAVPSL). The 
format of SAVPC and SAVPSL are shown in Figure 3-18. 


Figure 3-18 Console Saved PC and Saved PSL 


31 00 
Saved PC :SAVPC 
31 16 1514 13 08 07 00 


PSL<31:16> a Halt Code PSL<7:0> “SAVPSL 


MAPEN<0> 
Ivalid SAVPSL if 1 


LJ-01259-T10 


Console halts are discusssed in detail in Appendix D. 
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3.7.7 Kernel Stack Not Valid Exception 


A kernel stack not valid exception occurs when a memory management exception 
is detected while attempting to push information on the kernel stack during 
microcode processing of another exception. Note that a console halt with an error 
code of ERR_INTSTK is taken if a memory management exception is encountered 
while attempting to push information on the interrupt stack. 


The kernel stack not valid exception is dispatched through SCB vector 08 (hex) 
with the stack frame shown in Figure 3-19. 


Figure 3-19 Kernel Stack Not Valid Stack Frame 


31 00 
PSL 
LJ-01260-TI0 


3.8 System Control Block (SCB) 


The system control block (SCB) consists of two pages in main memory that contain the vectors 
by which interrupts and exceptions are dispatched to the appropriate service routines. The SCB 
is pointed to by IPR 17, the system control block base register (SCBB). The system control block 
base format is shown in Figure 3-20. The description of the format is in Table 3-11. 


Figure 3-20 System Control Block Base Register (SCBB) - IPR 17 


31 30 29 09 08 00 


MBZ Physical Longword Address of SCB MBZ 


LJ-01261-TI0 
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Table 3-11 The System Control Block Format 


ora Interrupt/Exception Name Type Pavan Notes 

00 Passive Release Interrupt 0 IPL is raised to request IPL 

04 Machine Check Abort 6 Parameters reflect machine state 

08 Kernel Stack Not Valid Abort 0 Must be serviced on interrupt 
stack 

0c Power Fail Interrupt 0 IPL is raised to 1E 

10 Reserved/Privileged Instruction Fault 0 

14 Customer Reserved Instruction Fault 0 XFC instruction 

18 Reserved Operand Fault/Abort 0 Not always recoverable 

1C Reserved Addressing Mode Fault 0 

20 Access Control Violation/Vector Fault 2 Parameters are virtual address, 

Alignment Fault status code 

24 Translation Not Valid Fault - 2 parameters are virtual address, 
status code 

28 Trace Pending (TP) Fault 

2C Breakpoint Instruction Fault 

30 Unused — — Compatibility mode in other VAX 
systems 

34 Arithmetic Trap/Fault 1 Parameter is type code 

38-3C Unused — — 

40 CHMK Trap 1 Parameter is sign-extended 
operand word 

44 CHME Trap 1 Parameter is sign-extended 
operand word 

48 CHMS Trap 1 Parameter is sign-extended 
operand word 

AC CHMU Trap 1 Parameter is sign-extended 
operand word 

50 Unused - - 

54 Memory Soft Error Notification Interrupt 0 IPL is 1A 

58-5C Unused - - 

60 Memory Hard Error Notification Interrupt 0 IPL is 1D 

64 Unused - - 

68 Vector Unit Disabled Fault 0 Vector instructions 
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Table 3-11 (Cont.) The System Control Block Format 


SCB # 
Offset Interrupt/Exception Name Type Params Notes 


6C-74 Unused = — 


78 Programmable Timer 0 Interrupt 0 IPL is 14 

7C Programmable Timer 1 Interrupt 0 IPL is 14 

80 Unused - - 

84 Software Level 1 Interrupt 0 

88 Software Level 2 Interrupt 0 Ordinarily used for AST delivery 

8C Software Level 3 Interrupt 0 Ordinarily used for process 
scheduling 

90-BC Software Levels 4-15 Interrupt 0 

Co Interval Timer Interrupt 0 IPL is 16 

C4 Unused - - 

C8 Emulation Start Fault 10 Same mode exception, FPD = 
0; parameters are opcode, PC, 
specifiers 

CC Emulation Continue Fault 0 Same mode exception, FPD = 1: 
no parameters 

108 Mass Storage Interface One Interrupt 0 IPL is 14 

(DSSI PORT 1) 
104 Mass Storage Interface Two Interrupt 0 IPL is 14 
(DSSI PORT 2) 

D8-DC Unused = 7 

FO Network Interface Interrupt 0 IPL is 14 

F4 Unused = - 

F8 Console Receiver Interrupt 0 IPL is 15 

FC Console Transmitter Interrupt 0 IPL is 15 

204 Interprocessor Doorbell Interrupt 0 IPL is 14 
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Vectors in the range of 100-FFFC are used to directly vector interrupts from the 
external bus. The SCB vector index is determined from bits <15:2> of the value 
supplied by external hardware. 


The new PSL priority level is determined by either the external interrupt request 
level that caused the interrupt or by bit <0> of the value supplied by external 
hardware. 


If bit<0> is 0, the new IPL level is determined by the interrupt request level 
being serviced. IRQ<3> sets the IPL to 1716; IRQ<2>, 164g; IRQ<1>, 154g ; and 
IRQ<0>, 141,. If bit<0> of the value supplied by external hardware is 1, then the 
new IPL is forced to 174g. 


The ability to force the IPL to 171g supports an external bus, such as the 
Q22-bus, which cannot guarantee that the device generating the SCB vector 
index is the device that originally requested the interrupt. 


For example, the Q22-bus has four separate interrupt request signals that 
correspond to IRQ<3:0> but only one signal to daisy chain the interrupt grant. 
Furthermore, devices on the Q22-bus are ordered so that higher priority devices 
are electrically closer to the bus master. If an IRQ<1> is being serviced, there is 
no guarantee that a higher priority device will not intercept the grant. 


Software must determine the level of the device that was serviced and set the IPL 
to the correct value. Only device vectors in the range of 100 to FFFC1¢ should be 
used, except by devices emulating console storage and terminal hardware. 


3.9 System Identification 


The KA680 firmware and operating system software references two registers 
to determine the processor on which they are running. The first, the system 
identification register (SID), is an internal processor register. The second, the 
system identification extension register (SIE), is a firmware register located in 
the KA680 EPROM. 


3.9.1 System Identification Register 


The system identification register (SID), IPR 62, is a read-only register 
implemented in the NVAX CPU. This 32-bit, read-only register is used to 
identify the processor type and its microcode revision level. The SID longword is 
read from IPR 62 using the MFPR instruction. This longword value is processor- 
specific. The format is shown in Figure 3—21. Bit definitions are listed in 

Table 3-12. 
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Figure 3-21 System Identification Register (SID) - IPR 62 


31 24 23 08 07 00 
LJ-01262-T10 


Table 3-12 System Identification Register 


Field Name RW Description 


<31:24> CPU_TYPE ro CPU type is the processor-specific identification code. 
<23:8> reserved ro Reserved for future use. 
<7:0> VERSION ro Version of the microcode. 


3.9.2 System Identification Extension (SIE) Register (20040004) 


The system identification extension register is an extension of the SID register 
and is used to further differentiate between hardware configurations. The SID 
register identifies which CPU and microcode are executing, and the SIE register 
identifies what module and firmware revision are present. Note that the fields in 
this register are dependent on SID<31:24>(CPU_TYPE). 


By convention, all MicroVAX systems implement a longword at physical location 
20040004 in the firmware EPROM for the SIE register. This 32-bit read-only 
register is implemented in the KA680 ROM. Figure 3—22 shows the format of this 
register. Table 3-13 lists the definitions of the register bits. 


Figure 3-22 System Identification Extension Register (SIE) 


31 24 23 16 15 08 07 02 01 00 
aaa i ese ad 
LJ-01263-T10 
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Table 3-13 System Identification Extension Register Bits 


Field Name RW Description 
31:24 SYS_TYPE ro This field identifies the type of system for a specific 
processor. 


01 : Q22-bus single processor system. 


23:16 VERSION ro This field identifies the resident version of the firmware 
EPROM encoded as two hexadecimal digits. For example, 
if the banner displays V5.0, then this field is 50 (hex). 


15:8 SYS_SUB_ ro This field identifies the particular system subtype. 
TYPE 
01 : KA650 
02 : KA640 
03 : KA655 
04 : KA670 
05 : KA660 
06 : KA680 


7:0 RESERVED This field is reserved 


3.10 CPU References 
All references by the CPU can be classified into one of the following groups: 


¢ Instruction-stream (I-stream) read references. 
¢ Data-stream (D-stream) read references. 

¢ Ownership read (OREAD) references. 

¢ Disown write (WDISOWN) references. 

¢ Write references. 


¢ Bad data write cycles (BADWDATA). See Section 4.4 for more information 
regarding the use of BADWDATA. 


3.10.1 Instruction-Stream Read References 


An instruction stream (I-stream) reference is defined as a read reference to 
acquire a VAX instruction. Furthermore, a VAX instruction consists of its 
opcode, all operand specifiers, and any operands that are necessarily contiguous 
with the rest of the instruction stream. Thus, the instruction stream includes 
short literals, immediate-mode operands, absolute addresses in absolute mode 
addressing, branch displacements, CALLx entry masks, and CASEx tables. 
Except for immediate-mode operands and branch displacements, the instruction 
stream does not include operands, even ones addressed relative to the PC. Except 
for absolute addresses, the instruction stream does not include indirect addresses. 
It also does not include EDITPC patterns. All instruction operands and indirect 
addresses not considered to be within the instruction stream are considered data, 
and are therefore accessed by the NVAX using D-stream read references. 


The CPU has an instruction prefetcher for prefetching program instructions 
from either cache or main memory. The prefetcher uses a 16-byte (4 longword) 
instruction prefetch queue (IPQ). Whenever there is an empty longword in the 
IPQ, and the prefetcher is not halted due to an error, the instruction prefetcher 
will generate an aligned quadword I-stream read reference. 
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3.10.2 Ownership Read References 


The NVAX uses ownership read (OREAD) references to gain ownership of a 
hexaword (32 bytes) block of memory. OREADs are defined only from memory 
space; they are not used in I/O space. 


The primary purpose for ownership reads on the KA680 CPU module is to 
facilitate the use of a write-back caching scheme. The backup cache on the 
KA680 CPU module uses a "write-back" scheme, whereby write transactions 

to cached memory locations result in the modification of the cached copy only 
(that is, the write transaction does not modify the actual memory location). This 
substantially reduces the time required for the write transaction, resulting in a 
corresponding improvement in system performance. 


This presents a potential problem for memory locations, which may be shared 
between the NVAX CPU and the I/O DMA devices, since the Bcache may contain 
the only up-to-date copy of a location referenced by a DMA device. Because of 
this, the KA680 memory subsystem utilizes the concept of memory ownership. In 
this scheme, each hexaword (32 bytes) of main memory has associated with it an 
ownership bit. These ownership bits reside on the KA680 CPU module and are 
controlled by the NVAX memory controller chip (NMC). Whenever a device on the 
module requests a transaction to main memory, the memory controller checks to 
see if the hexaword containing the referenced location is owned by another device 
(for example, the NVAX CPU or an I/O device). If it is owned, then the requested 
transaction is pended until the owner of the hexaword relinquishes ownership of 
that hexaword. In this way, the system can maintain memory consistency in the 
presence of the NVAX CPU write-back cache. 


The NVAX CPU will request ownership of memory locations in two general cases. 
The first is when software attempts to write to a location that is not currently 
cached in the Bcache AND owned by the CPU. In this case, the NVAX CPU will 
issue an OREAD to the memory subsystem to acquire ownership of the referenced 
hexaword. In this way, subsequent writes to the owned (and cached) location will 
occur only in the cache, and will not update the contents of the actual memory 
location. If another device wishes to access the owned hexaword, or if the CPU’s 
Bcache determines that it must deallocate the cache block containing the owned 
hexaword, then the NVAX CPU will perform a disown write (described below) 

of the owned hexaword to memory. The disown write updates memory with the 
potentially modified data, and signals the memory subsystem that the NVAX CPU 
is relinquishing ownership of that hexaword. 


The other case when the NVAX CPU will perform an OREAD to request 
ownership of a hexaword is for VAX instructions that perform interlocked 
read/modify/write operations on memory. The ownership mechanism is used in 
this case to prevent I/O or Q22—bus devices from accessing the relevant memory 
location in the middle of the read/modify/write operation. 


When memory receives an ownership read, an "owned" bit corresponding to the 
hexaword containing the referenced location is set in memory and the read data 
is returned. Each hexaword in memory has an ownership bit. The NVAX backup 
cache is organized by hexawords also, with an owned bit for each hexaword. 
Memory clears the owned bit when a disown write of any length is received for an 
owned block. 


If the ownership bit is already set in memory when the OREAD arrives, data is 
not returned immediately to the commander. Once the node that owns the data 
performs a disown write to the owned block, the ownership bit is set in memory 
and the data is returned to the commander. 
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For more information regarding the use of ownership bits in the KA680 system, 
refer to Chapter 5 and Section 4.4.2. 


3.10.3 Disown Write References 


The disown write (WDISOWN) transaction is the complement to the ownership 
read. After the NVAX CPU successfully gains ownership of a block in memory, 
it must relinquish ownership when another device (for example, a Q22—bus 
DMA device) wants to access the block or when the Bceache needs to do a 
deallocate. The NVAX CPU accomplishes this in a way transparent to software 
by deallocating the owned hexaword from the Beache and performing a disown 
write to the memory with the latest copy of the data. The memory, which has 
been monitoring the bus traffic, notices the disown write from the NVAX CPU 
and clears the ownership bit in memory and writes the new data. 


The NVAX CPU uses the disown write transaction of hexaword (32 bytes) length 
to perform writebacks from the backup cache. This is transparent to software 
except in the case of errors, when the logged information could indicate that an 
error occured during a disown write transaction. 


3.10.4 Data-Stream Read References 


Data-stream (D-stream) references are defined as all read references that do not 
fall under either OREAD or I-stream categories. Generally, D-stream references 
are used by the NVAX CPU to read instruction operands and data from memory. 
A more complete list of read references that qualify as D-stream is given below. 


¢ Operand 

¢ Page table entry (PTE) 

¢ System control block (SCB) 
¢ Process control block (PCB) 


When interlocked instructions, such as branch on bit set and set interlock 
(BBSSI) are executed, an OREAD/WDISOWN transaction pair is used to prevent 
I/O devices from accessing the referenced location in the middle of the instruction. 


3.10.5 Write References 


Whenever data is stored or moved, and a WDISOWN transaction is not in order, 
a normal WRITE reference is generated. 


3.11 NVAX Data/Address Lines (NDAL) 


3.11.1 NDAL Transactions 


The following sections describe the set of NDAL transactions. 


In order to maximize the bandwidth of the bus connecting the CPU to the memory 
and I/O controllers, the NVAX chip set (NVAX, NMC, NCA) communicate over a 
"pended" bus, the NDAL. The main feature of this bus is that devices requesting 
read data do not tie up the bus while waiting for the return data. Rather, a 
device will issue one of the "read" commands on the NDAL and then relinquish 
control of the bus to other devices so that other transactions may be performed. 
At the same time, the responder to the first device prepares to send back the data 
associated with the read request. Because of the pended nature of the bus, the 
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NDAL bus command set includes separate transactions for returning data from 
an earlier read cycle. Table 3-14 shows the entire set of NDAL commands and 
how they are used by NVAX. 


In memory space, NVAX issues all reads with hexaword length. Normal writes to 
memory space are always quadword length, and disown writes are quadword or 
hexaword. When the cache is operating normally, disown writes are only issued 
in hexaword length. When the cache is in error transition mode, NVAX issues 
disown writes of both hexaword and quadword length. For a discussion of error 
transition mode, refer to the section on the backup cache. 


When the cache is off, NVAX issues only quadword disown writes. NVAX issues 
quadword disown writes only as the result of a VAX interlocked instruction. 


In I/O space, the ownership commands (OREAD and Disown Write) are not 
defined at all. NVAX issues only quadword operations in I/O space. NVAX never 
uses the BADWDATA command in I/O space. 
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Table 3-14 NDAL Command Usage by NVAX 


Address Used by 
Space Command NVAX Length Length Length 
Qw Ow HW 
N/A Nop Yes - - - 
N/A Reserved No - - - 
Memory WRITE Yes Yes No No 
Memory WDISOWN Yes Yes No Yes 
Memory IREAD Yes No No Yes 
Memory DREAD Yes No No Yes 
Memory OREAD Yes No No Yes 
Memory RDE No - - - 
Memory WDATA Yes - - - 
Memory BADWDATA Yes - - - 
Memory RDRO No - - - 
Memory RDR1 No - - - 
Memory RDR2 No - - - 
Memory RDR3 No - - - 
VO WRITE Yes Yes No No 
VO WDISOWN' No No No No 
VO IREAD Yes Yes No No 
VO DREAD Yes Yes No No 
YO OREAD No No No No 
VO RDE No - - - 
VO WDATA Yes - - - 
VO BADWDATA No - - - 
VO RDRO No - - - 
VO RDR1 No - - - 
VO RDR2 No - - - 
YO RDR3 No - - - 
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3.11.1.1 Reads and Fills 
The read address cycle, which is recognized by one of the three read commands 
(DREAD, IREAD, or OREAD), is decoded by the NDAL devices that are receiving 
NDAL commands (only one of the NDAL chips may drive the bus at a time). The 
one recognizing the address latches that address and command. This device is 
the responder. The responder uses read data return (RDR) or read data error 
(RDE) cycles to return the data. Reads and fills are described in the following 
sections. The NVAX CPU never issues the RDR or RDE cycles, since it is never 
a direct responder to a read cycle. For examples of when the NVAX CPU may 
indirectly respond to a read transaction from the NCA, see the section on disown 
writes. 


3.11.1.1.1. D-stream Read Requests (DREAD) The NVAX CPU and the NCA 
use the DREAD command to request data-stream data from a responder, either 
memory or an I/O device. The NVAX CPU may issue DREAD cycles to the NMC 
or NCA. The NCA may issue DREAD cycles only to the NMC. 


3.11.1.1.2 I-stream Read Requests (IREAD) The IREAD command is used by 
the NVAX CPU and the NCA to request instruction-stream data. The NVAX CPU 
can request I-stream data from the NMC or the NCA. The NCA can request 
I-stream data only from the NMC. For more information regarding the difference 
between I-stream and D-stream references, see Section 3.10. 


3.11.1.1.3 Ownership Read Requests (OREAD) The NVAX CPU and the NCA 
use the OREAD command to gain ownership of a hexaword block of memory. 

In addition to facilitating the write-back cache of the NVAX CPU, the memory 
ownership concept is used to implement memory interlocks for VAX interlocked 
instructions. 


OREADs are only defined for memory space; they are not used in I/O space. 


When memory receives an ownership read, an "owned" bit is set in memory and 
the read data is returned. Each hexaword in memory has an owned bit. The 
NVAX backup cache is organized by hexawords also, with an owned bit for each 
hexaword. The memory controller clears the owned bit when a disown write of 
any length is received at the same block. 


If the ownership bit is already set in memory when the OREAD arrives, data 

is not returned immediately to the NDAL commander. An example of this is 

if an I/O device on one of the CP-buses attempts to access a buffer pointer in 
main memory and the referenced location is owned by the NVAX CPU. In this 
case, the NMC will notice that the ownership bit for the referenced hexaword 

is set and will pend the transaction. Simultaneously, the NVAX CPU, which 
constantly monitors the NDAL, has seen the reference to a location it owns, and 
will therefore write back the owned hexaword with a WDISOWN cycle. The NMC 
will then allow the original transaction from the NCA to complete. The opposite 
situation is also possible where the NCA may own a location that the NVAX CPU 
needs to access. The NCA does not have a write-back cache like the NVAX CPU, 
but the NCA will use the OREAD/WDISOWN transaction pair when performing 
interlocked references from I/O devices. 
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Through this ownership mechanism, the OREAD/WDISOWN transactions 
prevent access by the NCA (on behalf of I/O devices) to memory locations that 
may have become stale. This occurs because the NVAX CPU has modified the 
locations contents in the backup cache, but has not yet updated the actual 
memory location. 


During normal operation, the NVAX will aquire ownership, via an OREAD, of any 
memory space location that it needs to modify. Since this process also allocates 

a block in the backup cache for the referenced location, the NVAX CPU will 
virtually never need to perform writes directly to memory. Rather, memory will 
be modified with the updated values only when the associated Beache block must 
be written back to memory to make room in the Bcache, or because of an I/O 
reference to an owned location. Note that I/O space references are never cached, 
so writes to I/O space always appear on the NDAL. 


3.11.1.1.4 Read Data Return Cycles (RDRO, RDR1, RDR2, RDR3) The Read 
Data Return command is used in response to any read request, whether 
IREAD, DREAD, or OREAD. Multiple cycles are necessary to transfer all the 
quadwords in a given hexaword transaction, and the cycles are not required 

to be consecutive. The commander, which has been monitoring the bus traffic 
waiting for its return data, latches the information. The responder returns the 
commander ID with the returned read data so the commander can recognize the 
returned read data it requested. 


Because the NDAL is a pended bus, multiple reads may be outstanding at a time. 
Because read data return cycles do not have to occur contiguously, it is possible 
for read data return cycles resulting from different read requests to take place in 
an interleaved fashion. 


3.11.1.1.5 Read Data Error Cycles (RDE) RODE is used to notify a commander 

of a problem with read data that is being returned. For example, the NMC uses 
this command when it encounters an uncorrectable read error while processing a 
read request from the NVAX CPU or the NCA. 


3.11.1.2 Writes 


3.11.1.2.1| Normal Write Transactions (WRITE) These transactions are used to 
move a pattern of bytes from an NDAL commander to one of the responders. 


Parity must be correct for all bytes sent from any node because all three NVAX 
chips check parity across the entire NDAL during every cycle. 


If NVAX sees a write on the NDAL, it treats it as an invalidate request. In this 
case, the NVAX will perform a lookup of the backup cache tag store to see if the 
referenced location is contained in the backup cache. If it is, then the referenced 
cache block is invalidated. If the cache block is marked as owned, then the 
NVAX CPU also performs a write-back of the block to memory, since the data 
may be the only copy of valid data for that memory location. 
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3.11.1.2.2 Disown Write Transactions (WDISOWN) The disown write 
transaction is the complement to the ownership read. After NVAX successfully 
gains ownership of a hexaword block in memory, it must relinquish ownership if 
an I/O device wants to access the block (through the NCA) or when the Bceache 
needs to do a deallocate. The NVAX CPU accomplishes this by performing a 
disown write to the memory with the latest copy of the backup cache data. 

The memory, which has already pended the I/O device’s transaction, notices 
that the CPU’s transaction is a disown write. This condition allows it to clear 
the ownership bit in memory and to write the data as requested. Immediately 
following this, the memory controller allows the pended I/O device’s transaction 
to complete, since the referenced hexaword is no longer owned by the NVAX CPU. 


NVAX uses the Disown Write command of hexaword length to perform write- 
backs from the backup cache. When the cache is off, it uses quadword disown 
writes to achieve the effect of a write unlock for VAX interlocked instructions. As 
mentioned previously, the NCA also uses the OREAD/WDISOWN transaction pair 
when accessing main memory on behalf of I/O devices that use interlocked bus 
cycles. 


3.11.1.2.3 Write Data and Bad Write Data (WDATA,BADWDATA) The Write 
Data command is used during the data cycles of a write if the data is good. 

If the data has been corrupted in some way, the command used is Bad Write 
Data. An example of the use of BADWDATA is when the backup cache must 
deallocate an owned block to make room for new data or because of an I/O 
reference to that hexaword, and in the process of performing write-back, the 
NVAX CPU encounters uncorrectable errors in the cached data. In this case, the 
CPU will use the WDISOWN command, specifying the hexaword being disowned, 
followed by four data cycles to transfer each of the four quadwords of data. The 
bad quadword(s) will be marked through the use of the BADWDATA command 
instead of the WDATA command. 


When one quadword of a hexaword write disown is bad, the Bad Write Data 
command is only used for that quadword. The Write Data command is used for 
the good quadwords. The memory can use this information to distinguish which 
quadword of a hexaword block is bad. In addition, a soft error interrupt may be 
generated when a BADWDATA cycle is driven on the NDAL by the NCA. 


3.11.2 Cache Coherency 


Ownership reads and disown writes on the NDAL are intended to support the 
NVAX CPU’s writeback cache by attaching an owner status to each block in 
physical memory. A block in memory is defined as a hexaword, or 32 bytes. 
Once the NVAX CPU owns a block, it may write it repeatedly without accessing 
memory. A memory block may be owned either by the memory subsystem or 

by the NVAX CPU, but not both at the same time. Ownership is passed from 
memory to the NVAX CPU through an Ownership Read command. Ownership is 
passed back to the memory through a Disown Write command from the CPU. 


The ownership bits in the Bcache and in memory indicate which device owns the 
block: the Bceache or the NMC. The ownership bit in the Beache is set when it 
owns the block and is clear when memory (NMC) owns the block. The ownership 
bit in memory is set when the Bcache owns the block and clear when memory 
owns the block. The ownership bit corresponding to a hexaword of memory may 
also be set to indicate that the NCA owns the block. This is possible when the 
NCA is accessing memory on behalf of an I/O device that is using interlocked 
bus cycles on the CP-bus. In this case, the NCA will always follow the OREAD 
transaction immediately with the WDISOWN transaction. 
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Shared read-only access to a block is permitted only when memory owns it. 
Otherwise, the block can only be read by the node that owns the block. 


The NVAX can gain ownership and retain it for a very long time. The NVAX CPU 
monitors the bus continuously for memory space read-type and write commands 
to memory space by the NCA. When the CPU detects a request for a block that it 
owns, it will perform the disown write to memory, allowing the original command 
to complete successfully. Such NDAL transactions, which take place solely for 
the purpose of maintaining the ownership protocol, are referred to as "cache 
coherency transactions." 


Table 3-15 shows what action is performed in the backup cache based upon the 
state of the block in the cache when a particular command is driven onto the 
NDAL by the NCA. 


Table 3-15 NVAX Backup Cache Invalidates and Write-backs 
NDAL Command Invalid Block Valid & Unowned Valid & Owned 


IREAD,DREAD - - Write-back, 
set Bcache to 
valid-unowned 


state 
OREAD - Invalidate Write-back, 

Invalidate 
WRITE - Invalidate Write-back, 

Invalidate 


WDISOWN - — - 


The I/O devices connected to the NCA through the CP-buses may cause the 
NCA to access memory on their behalf. As these transactions go to memory, 

the NVAX CPU recognizes them and performs the appropriate cache coherency 
action. The NVAX CPU does not acknowledge the commands, since the memory 
interface is the receiver for the transaction. The NVAX CPU distinguishes cycles 
driven by devices other than itself by decoding the commander’s ID. The ID 

is driven onto the NDAL along with the command, and recognizes those NCA 
initiated cycles as cache coherency transactions. 
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3.11.3 VAX Architecturally-defined Interlocks 


A VAX interlocked instruction causes the generation of a read-lock and a write- 
unlock, which are guaranteed to happen back-to-back. The NDAL does not 
explicitly define interlocked transactions. Instead, the Ownership Read command 
is used in place of Read Lock and the Disown Write command is used in place of 
Unlock Write. 


If the interlocked location is already owned in the backup cache, then there is no 
need to issue an OREAD on the NDAL, and it is serviced directly by the Bcache. 


It is also possible for I/O devices to cause the NCA to issue OREAD/WDISOWN 
pairs on the NDAL for the purpose of performing interlocked access to VAX 
memory. 


3.11.3.1 Ownership and Interlock Transactions 
The NVAX CPU does not support interlocks to I/O space. If software attempts to 
perform an interlocked instruction on an I/O space address, the NVAX CPU will 
use normal DREAD/WRITE accesses to complete the operation. No interlock is 
provided. 


3.11.4 Errors 


The NDAL supports the detection of all single-bit and some multiple-bit 
transmission-related error conditions on the NDAL_H, CMD_H, ID_H, and 
PARITY_H lines by implementing parity across those lines. Additionally, the 
NDAL allows commanders to recover from some memory and I/O-space read/write 
class errors. 


3.11.4.1. Transaction Timeout 
The NVAX CPU and NCA implement timeout counters for each read that they 
may have outstanding. The NVAX implements two timeout counters, one for each 
possible outstanding read. If a read request times out, it is aborted by the NVAX 
and a soft error interrupt is generated. Any missing read data return cycles will 
eventually cause that read to timeout in the NVAX CPU. See Section 4.4.10 for 
details on how timeout is handled. 


Transaction timeout is not a normal occurrence and is expected to happen only on 
serious system failures. 


3.11.4.2 Nonexistent Memory and I/O 
An address that is not implemented in memory on a particular system is known 
as nonexistent memory. An I/O address of a device that is not present on a 
particular system is known as nonexistent I/O. When software attempts to access 
addresses that are nonexistent, an error interrupt will be generated. 
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The NVAX memory subsystem has a hierarchical structure. The VIC, Pcache, 
Bcache, Main Memory, and finally the Mass Storage form the hierarchical 
memory subsystem of the KA680. The hierarchical order of the levels of KA680 
memory is shown in Figure 4-1. 


Figure 4-1 KA680 Cache/Memory Hierarchy 


Main Memory 


Backup Cache 128 KB 


Primary Cache 8KB 


VIC 2KB 


For I-stream references, the memory hierarchy starts with the VIC, whereas for 
D-stream references, the memory hierarchy starts with the Pcache. 


References generated by the NVAX CPU are issued to the memory subsystem 

at the first hierarchical level, as determined by the reference type (I-stream or 
D-stream). The reference will then pass up through the hierarchy until it is 
serviced by one of the layers. References serviced at lower layers take less time 
than references that must pass to higher layers. For this reason, it is the intent 
of the memory subsystem to service most references within the lower layers, thus 
maximizing system performance. 


By creating successively faster layers of memory hierarchy below the main 
memory, the KA680 decreases the average amount of time required to access 
information. Because each layer in the hierarchy tends to be smaller in size than 
the next higher (slower) layer, there is the problem of allocating space at each 
layer for storing references. Furthermore, care must be taken to ensure that the 
state of the system is singularly and accurately represented by the combined 
contents of the caches and main memory. 
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In the KA680, this issue is most critical between main memory and the backup 
and primary caches, because main memory can be accessed by DMA devices 

as well as the NVAX CPU. Furthermore, this problem is complicated by the 
write-back nature of the backup cache. This write-back mechanism, while 
significantly decreasing the latency of write operations, complicates the problem 
of maintaining a coherent and consistent representation of main memory in DMA 
traffic. 


For example, during normal operation, the NVAX CPU and DMA devices will 
share access to certain memory locations. In order to guarantee proper operation, 
the KA680 provides hardware mechanisms to ensure that DMA updates to main 
memory will be invalidated in the primary and backup caches. Furthermore, the 
KA680 provides mechanisms to ensure that DMA traffic is presented with correct 
data in the presence of the write-back cache. The following sections discuss each 
of the caches and how they are used. 


4.1 Cacheable References 


Any reference that can be stored by the virtual instruction cache, or the primary 
or backup caches, is called a cacheable reference. The primary and backup caches 
store CPU read references to the VAX memory space (bit <29> of the physical 
address = 0) only. They do not store references to the VAX I/O space. 


Whenever the CPU generates a noncacheable reference, or a cacheable reference 
not stored in any of the three caches, a single hexaword reference of the same 
type is generated on the NDAL bus. 


Whenever the CPU generates a cacheable reference that is stored in one of the 
caches, no reference is generated on the NDAL bus. 


4.2 Virtual Instruction Cache 


Before any instruction can be executed, it must first be fetched from memory. 
The NVAX CPU contains an instruction prefetcher, which fetches sequential 
instructions ahead of the instruction currently being executed. This is done in an 
attempt to reduce the effective access time of the instruction fetch by pipelining it 
with decode and instruction execution. The instruction prefetcher maintains an 
instruction prefetch queue (IPQ) of up to 16 bytes (4 longwords) of I-stream data. 
In order to fill the IPQ, the prefetcher sends I-stream read requests to the virtual 
instruction cache. 


The virtual instruction cache (VIC) is a 2 KB, direct-mapped cache for caching 
I-stream data. The VIC is located within the NVAX CPU chip. In order to 
reduce the overhead associated with virtual-to-physical address translation, the 
VIC caches references based on virtual addresses. In the event that the virtual 
references made by the instruction prefetcher hit in the VIC, the I-stream data is 
loaded from the VIC directly to the IPQ. 


If the references made by the instruction prefetcher miss in the VIC, then the 
VIC will issue an I-stream read request on behalf of the instruction prefetcher to 
the next level of memory hierarchy: the primary cache. 
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4.2.1 Virtual Instruction Cache Organization 


The VIC attributes are summarized in Table 4—1. 


Table 4-1 VIC Attributes 


Attribute Description 

Cache Size 2 KB 

Access Type Direct-mapped 

Block Size 32 bytes 

Subblock Size 8 bytes 

Valid Bits 4 valid bits/cache block = 1 per subblock 

Data Parity Bits 4 even parity bits/cache block = 1 per subblock 

No. of Tags 64 tags 

Tag Parity Bit 1 even parity bit per tag 

Fill Algorithm Fill forward, random cycle allocate if no tag hit or data subblock 


Access Size 

Bus Size 
Prefetching 
Data Stored 
Virtual/Physical 


valid 

8 bytes 

8 bytes 

None 
I-stream only 
Virtual 


The format of each cache row is shown in Figure 4—2. Each cache row stores a 
22-bit tag with even parity for the tag, and four quadword subblocks, each with a 
valid bit and an even parity bit that covers the data only. During a cache read, 
the data, tags, valid and parity bits of the direct-mapped cache block are read. 
The tag is compared to bits <31:10> of the virtual address. If the tag matches, 
then the data is returned to the instruction prefetch queue. Otherwise, the 
request has "missed" in the VIC, and the read request is forwarded to the Pcache. 


Figure 4-2 VIC Cache Row Format 


21 00 63 00 63 00 63 00 63 00 
Sub-block Sub-block Sub-block Sub-block 
Ae yf 
a 


287 Bits 
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Macrocode Restriction 


To avoid parity errors, the VIC tag arrays, including parity, must be 
written with valid data and parity before enabling the VIC. The tag 
values in bank 0 must be written with different values than the tag 
values in bank 1 so that the tags from both banks do not simultaneously 
produce a tag hit. 


4.2.2 Virtual Instruction Cache Internal Processor Registers 


The VIC contains four internal processor registers, which provide VIC control and 
read/write access to the data and tag arrays. 


Macrocode Restriction 


The VIC_ENABLE bit of the ICSR IPR must be cleared before writing 
to the other VIC IPRs VMAR, VDATA, or VTAG. Similarly, the VIC_ 
ENABLE bit of the ICSR IPR must be cleared before reading from the 
VIC IPRs VDATA and VTAG. 


4.2.2.1 VIC Virtual Memory Address Register (VMAR) - IPR 208 


Figure 4-3 VMAR Register 


31 11 10 05 04 03 02 01 00 
:-VMAR 
ROW_INDEX 
SUB_BLOCK 
Lw 
LJ-01265-T10 
Table 4-2 VMAR Register 
Name Extent Type Description 
LW 2 WO Longword select bit. Selects longword of 
subblock for access to cache array. 
SUB_BLOCK 4:3 RW Subblock select. Selects data subblock 


for access to cache array; also latches 
bits <4:3> of the virtual address on VIC 
parity errors. 

ROW_INDEX 10:5 RW Row select. Row index for read and 
write access to cache array; also latches 
bits <9:5> of a virtual address, which 
resulted in a VIC parity error. 


(continued on next page) 
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Table 4-2 (Cont.) VMAR Register 


Name Extent Type Description 


ADDR 31:11 RO Error address field. Latches tag portion 
of the virtual address, which resulted in 
a VIC parity error. 


When the VIC is disabled, the VIC memory address register (VMAR) may be used 
as an index for direct IPR access to the cache arrays. Bits <9:5> of this register 
supply the cache row index, bit <10> selects the bank, bits <4:3> supply the cache 
subblock, and bit <2> indicates the longword within a quadword address. 


The VMAR IPR also latches and holds bits <31:3> of the virtual address of the 
reference that resulted in a parity error on VIC array parity errors. 


4.2.2.2 VIC TAG Register (VTAG) - IPR 209 


Figure 4-4 VTAG Register 


31 11 10 09 08 07 04 03 00 
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Table 4-3 VTAG Register 


Name Extent Type Description 

Vv 3:0 RW Data valid bits. Supply data valid bits 
on array read/writes. 

DP 7:4 RW Data parity bits. Supply data parity on 
array read/writes. 

TP 8 RW Tag parity bit. Supplies tag parity on 
tag array read/writes. 

TAG 31:11 RW Tag. Supplies tag on tag array 
read/writes. 


The VTAG IPR provides read and write access to the cache tag array. An IPR 
write to VIAG will write the tag, parity, and valid bits for the row indexed by 
VMAR<9:5> and the bank selected by VMAR<10>. VTAG<31:10> are written to 
the cache tag. VTAG<8> is written to the associated tag parity bit. VTAG<7:4> 
are used to write the four data parity bits associated with the indexed cache 
row. Similarly, VTAG<3:0> write the four data valid bits associated with the 
cache row. VTAG<7:4> and VTAG<3:0> are the data parity and data valid bits, 
respectively, for the four quadwords of data in the same row. VTAG<4> and 
VTAG<0> correspond to the quadword of data addressed when address bits 4:3 = 
00; VTAG<5> and VTAG<1> correspond to the quadword of data addressed when 
address bits 4:3 = 01, and so forth. 


KA680 Cache Memory Overview 4-5 


KA680 Cache Memory Overview 
4.2 Virtual Instruction Cache 


4.2.2.3. VIC Data Register (VDATA) - IPR 210 


Figure 4-5 VDATA Register 


31 00 
LJ-01319-Tl0 


Table 4-4 VDATA Register 


Name Extent Type Description 


DATA 31:0 RW Data for data array reads and writes 


The VDATA IPR provides read and write access to the cache data array. When 
VDATA is written, the cache data array entry indexed by the VMAR IPR is 
written with the IPR data. Since the IPR data is a longword, two accesses to 
VDATA are required to read or write a quadword cache subblock. 


Writes to VDATA with VMAR<2> = 0 simply accumulate the IPR data destined 
for the low longword of a subblock in a scratch register internal to the 

NVAX CPU. A subsequent write to VDATA with VMAR<2> = 1 triggers a cache 
write to the subblock indexed by VMAR. 


Reads to VDATA with VMAR<2> = 0 trigger a cache read to the subblock indexed 
by VMAR. The low longword of a subblock is returned as IPR read data. A read 
of VDATA with VMAR<2> = 1 returns the high longword of the subblock as IPR 
data. 
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4.2.2.4 VIC Control and Status Register (ICSR) - IPR 211 


Figure 4-6 ICSR Register 


31 05 04 03 02 01 00 


TPERR_O 
DPERR_0O 
LOCK 
ENABLE 
LJ-01318-TI0 
Table 4-5 ICSR Register 
Name Extent Type Description 
ENABLE 0 RW,0 Enable bit. When set, allows cache 


access to the VIC. Initializes to 0 on 
system reset. 


LOCK 2 WC Lock bit. When set, validates and 
prevents further modification of the 
error status bits in the ICSR and the 
error address in the VMAR register. 


When clear, indicates no VIC parity 
error has been recorded and allows ICSR 
and VMAR to be updated. 


DPERR 3 RO Data error bit. When set, indicates data 
parity error occurred in data array. 
TPERR 4 RO Tag error bit. When set, indicates tag 


parity error occurred in tag array. 


The ICSR IPR provides control and status functions for the VIC. VIC tag and data 
parity errors are latched in the read-only bits ICSR<4:3>, respectively. ICSR<2> 
is set when a tag or data parity error occurs, and keeps the error status bits 
and the VMAR IPR from being modified further. Writing a logic one to ICSR<2> 
clears the lock bit and allows the error status to be updated. When ICSR<2> is 
clear, the values in ICSR<4:3> are meaningless. When ICSR<2> is set, a VIC 
parity error has occurred, and either ICSR<4> or ICSR<3> will be set. This 
indicates that the parity error was either a tag parity error or a data parity error, 
respectively. ICSR<4:3> cannot be cleared from software. ICSR<0> provides IPR 
control of the VIC enable. It is cleared on system reset. 
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4.3 Primary Cache 


The Pcache is a 2-way set associative, read allocate, no-write allocate, write- 
through, physical address cache of I-stream and D-stream data. It stores 

8192 bytes (8K) of data and 256 tags corresponding to 256 hexaword blocks (1 
hexaword = 32 bytes). Each tag is 20 bits wide, corresponding to bits <31:12> of 
the physical address. 


There are four quadword subblocks per block with a valid bit associated with 
each subblock. The access size for both Pcache reads and writes is one quadword. 
Byte parity is maintained for each byte of data (32 bits per block). One bit of 
parity is maintained for every tag. The Pcache has a 1-cycle access and a 1-cycle 
repetition rate for both reads and writes. 


The Pcache represents the first level of D-stream memory hierarchy and the 
second level of I-stream memory hierarchy in all NVAX computer systems. 
Pcache entries must be invalidated in order to maintain cache coherency with 
higher levels of the memory hierarchy. See Section 4.3.2 for more information on 
the Pcache. 


The Pcache is located within the NVAX CPU chip. Unlike the VIC, the Pcache 
is based on physical addresses rather than virtual addresses. The Pcache 
handles I-stream requests from the VIC, as well as D-stream requests for 
instruction operands. The Pcache uses a write-through scheme for handling 
writes to memory locations that are contained in the Pcache. In this scheme, the 
write operation updates the contents of the Pcache, and the write operation is 
propagated to the next level of memory hierarchy: the backup cache. The Pcache 
is maintained as a strict subset of the backup cache. 


4.3.1 Primary Cache Organization 
Figure 4—7 shows the logical organization of the Pcache. 
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Figure 4—7 Logical Pcache Organization 


=«—__—_—— Left Bank >< Right Bank ———_____> 


127: A | TP} Tag | VB| D/DP| D/DP| D/DP| D/DP| TP | Tag | VB | D/DP| D/DP | D/DP| D/DP 


Where: A= Allocation bit. Indicates whether the left of right bank was last allocated. 
TP = 1 bit of even tag parity. 
Tag = 20 bits of tag address. 
VB = 4 valid bits. each bit corresponds to 8 bytes of data. 
D/DP = 8 bytes of data with 8 bits of even byte parity (72 total bits). 
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The Pcache is logically organized into 128 direct-mapped indexes, where each 
index consists of two blocks, and each block consists of: 20-bit tag, 1-bit tag 
parity, 4 valid bits, 256 bits of data, and 32 bits of data parity. In addition, each 
index also contains a 1-bit allocation pointer. 


The breakdown of address bits for Peache decoding is shown below: 


Figure 4-8 Pcache Address Breakdown 


12 11 05 04 03 02 01 00 


Tag Address Index Address fe Hela 


Sub-block Address 


Where: Tag Address = Bits loaded into or compared with tag. 
Index Address = Address 1 of 128 indexes. 
Sub-block Address = Addresses 1 of 4 aligned quadwords within the hexaword data block. 
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4.3.2 Pcache Control 


The Pcache is controlled through the PCCTL internal processor register. This 
IPR controls whether the Pcache is enabled or disabled, as well as controlling 
the general mode of operation. As with other internal processor registers, it is 
accessible through the MTPR and MFPR instructions. The following diagram 
shows the organization of the PCCTL internal processor register. 
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Figure 4-9 PCCTL Register 


31 30 29 28 27 26 25 24 23 22 21 20 1918 17 16 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00 


Reserved 
Reserved 
P_Enable 
Bank_SEL 
Force_HIT 
|_Enable 


D_Enable 


Table 4-6 PCCTL Definition 


:~PCCTL 
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Name Extent Type 


Description 


D_ENABLE 0 RW,0 


I_ENABLE 1 RW,0 
FORCE_HIT 2 RW,0 
BANK_SEL 3 RW,0 
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When set, enables Peache for all 
invalidate operations and for all 
D-stream read/write/fill operations. 
Qualified by other control bits. 


When clear, forces a Pcache miss on 
all Peache D-stream read/write/fill 
operations. Note, however, that an 
ACV/TNV/ME=0 condition overrides a 
deasserted D_ENABLE because it will 
force a Peache hit condition with D_ 
ENABLE=0. 


When set, enables Pcache processing of 
invalidate, I-stream read and I-stream 
cache fills. 


When clear, forces a Peache miss on 
I-stream read operations and prevents 
state modification due to an I-stream 
cache fill operation. 


Note, however, that an ACV/TNV/M=0 
condition overrides a deasserted I_ 
ENABLE because it will force a Pcache 
hit condition with IENABLE=0. 


When set, forces a Peache hit on all 
reads and writes when Pcache is enabled 
for I- or D-stream operation. 


This is used for diagnostic purposes so 
that the cache data store can be directly 
accessed. 


When set with FORCE_HIT=1, selects 
the "right bank" of the addressed Pcache 
index. 


(continued on next page) 
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Table 4-6 (Cont.) PCCTL Definition 
Name Extent Type Description 


When clear with FORCE_HIT=1, selects 
the "left bank" of the addressed Pceache 
index. 


This bit is a don’t care when FORCE_ 
HIT=0. 


P_ENABLE 4 RW,0 When set, enables detection of Pcache 
tag and data parity errors. 


When deasserted, disables Pcache parity 
error detection. 


Reserved 7:5 R,1 Unused. Read as ones. 
Reserved 8 R,0 - 
Reserved 9 R,0 Pcache redundancy bit. When set, this 


bit indicates that one or more Pcache 
redundant elements have been enabled. 


Note that Pcache operation is further qualified by the state of PCSTS<0>. If 
this bit is nonzero, Pcache operation is automatically forced to behave as if I_ 
ENABLE=0 and D_ENABLE=0, regardless of the actual state of IENABLE and 
D_ENABLE. Effectively, this shuts down normal Pcache operation due to the 
presence of a previous Pcache parity error. 


Based on the bit definitions above, note that Pcache invalidate operations are 
only disabled if both DLENABLE=0 and I ENABLE=0, or if PCSTS<0> is set. 
Also note that Pcache IPR read and write operations are always unconditionally 
enabled, regardless of the state of ENABLE or D_LENABLE, or PCSTS<0>. 


If either DLENABLE or IENABLE are to be toggled to the on state, the Pcache 
array must be initialized prior to such action. 


When the FORCE_HIT (force hit) bit is set and I-stream or D-stream operation is 
enabled, all enabled memory space read and write references are forced to hit in 
the Pcache. The BANK_SEL bit specifies which tag of the pair of tags addressed 
is forced to hit. Thus when FORCE_HIT=1, the Pcache becomes a 4K direct- 
mapped cache with all reads and writes forced to hit in the Pcache. Toggling 
BANK_SEL causes the other half of the 8K Pcache to become accessible in this 
direct mapped mode. Note that the FORCE_HIT bit only affects memory space 
references. I/O space references still miss in the Pcache regardless of the state of 
the FORCE_HIT bit. 


The FORCE_HIT feature is designed to facilitate testing the Pcache data array 
and to make diagnostic tests easily loadable within the Pcache by simple memory 
write operations. When FORCE_HIT=0, the Pcache is configured as an 8K 2-way 
set associative cache, no reads or writes are forced to hit, and the BANK_SEL bit 
is a don’t care. 


The P_ENABLE (parity enable) bit allows the detection of Pcache tag and data 
parity errors to be enabled or disabled. If PLENABLE=0, Pcache parity errors 
will not be detected. Thus when P_ENABLE=0, no Pcache error will be recorded 
in PCSTS, nor will they cause an error interrupt or machine check. 


Note however, that when FORCE_HIT=1, Pcache tag parity is never checked 
regardless of the state of PLENABLE. 
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4.3.3 Pcache Hit/Miss Determination 


4.3.3.1 Hit/Miss Determination by Tag Comparison 
For I-stream or D-stream reads or writes, the Pcache must determine if the 
referenced data is present in its array. To do this, physical address bits <11:5> 
are input to the Pcache row decoders in order to determine which one of the 128 
direct-mapped indexes is being addressed. Subsequently, all 627 bits within the 
addressed index are accessed by the assertion of the corresponding word line. 
The two accessed tag values are simultaneously compared to physical address 
bits<31:12>. A Peache hit condition occurs when all of the following conditions 
are simultaneously true: 


¢ The contents of one of the two addressed tags matches the data on physical 
address bits <31:12>. 


¢ The valid bit corresponding to both the matched tag and to the addressed 
quadword subblock (specified by physical address bits<4:3>) is set. 


¢ The stored tag parity corresponding to the matched tag is the same as the 
value calculated from bits <31:12>. 


If an address match is detected on one of the tags and the valid bit that 
corresponds to both the matched tag and the addressed subblock (specified by 
physical address bits <4:3>) is set, then a Pcache hit condition has been detected 
on the corresponding Pcache tag. The absence of the Pcache hit condition causes 
a Pcache miss condition. 


4.3.3.2 Conditions That Force Pcache Miss 
The Pceache miss condition is forced to override the tag determination of hit/miss 
described above when any one of the following conditions is satisfied: 


¢ If PCSTS<0> is set, the Pcache miss condition is forced due to a previous 
Pcache parity error. 


¢ If an I-stream read or cache fill operation is accessing the Pcache and I_ 
ENABLE =0, the Pcache miss condition is forced. 


e Ifa D-stream read or cache fill operation is accessing the Pcache and D_ 
ENABLE =0, the Pcache miss condition is forced. 


¢ Ifa D-stream read lock operation is executing (such as for an interlocked 
instruction), the Pcache miss condition is forced. This guarantees that the 
read will propagate to the Bcache where memory ownership can be obtained 
for synchronization purposes. 


e If an I-stream cache fill operation is executing, but the reference is 
noncacheable, the Pcache miss condition is forced. 


¢ Ifa D-stream cache fill operation is executing, but the reference is 
noncacheable, the Pcache miss condition is forced. 
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4.3.3.3 Conditions That Force Pcache Hit 


The Pcache hit condition is forced to override the tag determination of hit/miss 
described above when any one of the following conditions is satisfied: 


¢ Ifa read or write reference has a memory management fault or hard error 
associated with it, a Pcache hit condition is forced. NOTE: This force hit 
condition takes precedence over any force miss condition described 
above. 


e¢ Ifthe operation is a D-stream read, write or WRITE_UNLOCK, and D_ 
ENABLE=1 and FORCE_HIT=1, the Pcache hit condition is forced on the tag 
corresponding to both the addressed Pcache index and the bank specified by 
the BANK_SEL bit. 


e Ifthe operation is an I-stream read and I ENABLE=1 and FORCE_HIT=1, 
the Peache hit condition is forced on the tag corresponding to both the 
addressed Pcache index and the bank specified by the BANK_SEL bit. 


4.3.4 Pcache Behavior on Write Operations 


A Pcache write operation is initiated by a write or WRITE_UNLOCK reference. 
A Pcache write begins by determining the Pcache hit or miss condition described 
above. If a Pcache hit is detected, the data is selectively written into the 
quadword corresponding to both the tag in which the hit occurred and to physical 
address bits <4:3>. The data is selectively written according to the length 
specified in the instruction causing the write. The corresponding data parity is 
also written in the same manner for each corresponding byte that is written. 


If a Pcache miss condition occurs, no Pcache write operation takes place. 
However, the write reference is forwarded to the Bcache for processing regardless 
of the hit/miss condition in the Pcache. 


4.3.5 Pcache Replacement Algorithm 


When a Pcache miss occurs during a read operation, it must be decided which one 
of two blocks will be allocated for the subsequent Pcache fill sequence. When the 
Pcache miss occurred because no validated tag field matched the read address, 
the state of the corresponding allocation bit indicates which bank (left or right) 
should be used for the resulting fill sequence. The value of each allocation bit 
changes according to the "not-last-used" algorithm. That is, the allocation bit 
always points to the bank within the index that was not last accessed. 


When a read miss occurs because no validated tag field matched the read address, 
the value of the allocation bit will be used as the bank select input during the 
subsequent fill sequence. As each fill operation takes place (that is, as each 
quadword comes back from memory), the allocation bit is written to point to the 
other bank. This ensures that the next fill operation to this cache entry will be 
written to the other bank. Also, during Pcache read or write operations, the value 
of the allocation bit is set to point to the opposite bank that was just referenced 
because this is now the new "not-last-used" bank. 


The one exception to this algorithm occurs during an invalidate. Pcache 
invalidates occur because of I/O activity in the system and the need to maintain 
the Pcache as a strict subset of the Bcache. When a Pcache invalidate clears 
the valid bits of a particular tag within an index, set the allocation bit to point 
to the bank select used during the invalidate regardless of which bank was last 
allocated. By doing so, it is guaranteed that the next allocated block within the 
index will not displace any valid tag because the allocation bit points to the tag 
that was just invalidated. 
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4.3.6 Pcache Fill Operation 


A Peache fill operation is initiated by an I-stream or D-stream read operation that 
missed in the Pcache. A fill is functionally identical to a Peache write operation 
from write reference except for the following differences: 


¢ The bank within the addressed Pcache index is selected by the following 
algorithm. If a validated tag field within the addressed index matches the 
cache fill address, then the block corresponding to this tag is used for the fill 
operation. If this is not true, then the value of the corresponding allocation 
bit selects which block will be used for the fill. 


¢ The first fill operation to a block causes all four valid bits of the selected bank 
to be written so that the valid bit of the corresponding fill data is set and the 
other three are cleared. All subsequent fills cause only the valid bit of the 
corresponding fill data to be set. 


e Any fill operation causes the fill address bits <31:12> to be written into the 
tag field of the selected bank. Tag parity is also written in an analogous 
fashion. 


e A fill operation causes the allocation bit to be written with the complement of 
the value it had at the time of the reference that missed and caused the fill 
sequence. 


¢ A fill operation forces every bit of the corresponding byte mask field to be set. 
Thus, all eight bytes of fill data are always written into the Pcache array on a 
fill operation. 


4.3.7 Pcache Invalidate Operation 


A Pcache invalidate operation is initiated by I/O activity to main memory and 
the need to maintain the Pcache as a strict subset of the Beache. During I/O 
activity, the I/O devices may update main memory, which is cached in the Bcache 
and possibly the Pcache. When such references occur, the caches must invalidate 
their copies of the referenced memory location, because they are now stale. The 
invalidate operation is interpreted as a NOP by the Pcache if the address does 
not match either tag field in the addressed Pcache index. If a match is detected 
on either tag, an invalidate will occur on that tag. Note that this determination 
is made based only on a match of the tag field bits rather than on satisfying all 
criteria for the Peache hit condition (Pcache hit factors in valid bits and verified 
tag parity into the equation). 


When an invalidate is to occur, the four valid bits of the matched tag are written 
with zeros and the allocation bit is written with the value of the bank select used 
during the current invalidate operation. 


Also note that an uncorrectable error, either in the Bcache or in main memory 
during a cache fill sequence, causes the cache fill operation to be processed as if it 
were an INVAL operation. 
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4.3.8 Pcache IPR Summary 


The following table summaries all IPRs associated with the Pcache: 


Table 4-7 Pcache IPRs 
Register Name IPR Address (in hex) 


PCADR (quadword address of reference FO 
causing Pcache parity error) 


PCSTS (status of Pcache parity error) F1 

PCCTL (control state of Pcache F2 

operation) 

PCTAG 01800000..01801FE0 
PCDAP 01C00000..01C01FF8 


4.3.8.1. PCADR - IPR 240 


Figure 4-10 PCADR Register 


31 03 02 01 00 
Quadword Physical Address Associated with the Recorded Pcache Parity Error fo ° :PCADR 
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4.3.8.2 PCSTS - IPR 241 


Figure 4-11 PCSTS Register 


31 30 2928 27 26 25 24 23 22 21 20 1918 17 16 15 14 13 12 11 10 09 08 04 03 02 01 00 


PTE_ER 


:PCSTS 


PTE_ER_WR 


LEFT_BANK 
RIGHT_BANK 


DPERR 
LOCK 
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Table 4-8 PCSTS Description 
Name Extent Type Description 


LOCK 0 WC,0 Lock bit. When set, validates 
PCSTS<8:1> contents and prevents 
modification of these fields. 


When clear, invalidates PCSTS<8:1> 
and allows these fields and PCADR to be 


modified. 
DPERR 1 RO Data error bit. When set, indicates a 
Pcache data parity error. 
RIGHT_BANK 2 RO Right bank tag error bit. When set, 


indicates a Pcache tag parity error on 
the right bank. 


LEFT_BANK 3 RO Left bank tag error bit. When set, 
indicates a Pcache tag parity error on 
the left bank. 


RESERVED 8:4 RO - 

PTE_ER_WR 9 WC,0 Indicates a hard error on a data read 
from a page table entry, which resulted 
from a TB miss on a write or WRITE_ 
UNLOCK. 

PTE_ER 10 WC,0 Indicates a hard error on a data read 


from a page table entry. 


4.3.8.3 PCCTL - IPR 242 


See Figure 4—9 in Section 4.3.2 for information regarding the format and use of 
this register. 


4.3.8.4 PCTAG - IPRs 01800000, to 01801FE01¢ 


Figure 4-12 PCTAG Register 


12 11 10 09 08 07 06 05 04 03 02 01 00 
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Name Extent Type Description 
A 0 RW Allocation bit corresponding to index of 
this tag 
Valid bits 4:1 RW Valid bits corresponding to the four data 
subblocks 
PCTAG<4> corresponds to uppermost 
quadword in block 
PCTAG<1> corresponds to lowermost 
quadword in block 
P 5 RW Even tag parity 
Tag 31:12 RW Tag data 
4.3.8.5 PCDAP - IPR 01000000, to 01C01FF8,, 
Figure 4-13 PCDAP Register 
31 30 29 28 27 26 25 24 23 22 21 20 1918 17 16 15 14 13 12 11 10 09 08 07 00 
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Table 4-10 Pcache Data Parity IPR Format 


Name Extent 


Type 


Description 


DATA_PARITY 7:0 


RW 


Even byte parity corresponding to 
addressed quadword of data. Bit n 
represents parity for byte n of addressed 
quadword. 
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4.3.9 Pcache IPR Access 


For testability reasons, it is important to verify that every Pcache storage bit can 
be read and written in both "0" and "1" states. The easiest way to do this is to 
directly read and write every bit in the Pcache array. The data field is accessible 
through reads and writes to addresses that hit in the Peache. (The hit condition 
can be forced through setting the FORCE_HIT bit in the PCCTL IPR.) The tag 
field, tag parity, valid bits, and data parity are directly accessible through MTPR 
and MFPR instructions to the Pcache IPRs defined below. 


Figure 4-14 IPR Address Space Mapping 


Normal IPR Address 


31 25 24 23 08 07 00 


SBZ 0 SBZ IPR Number 


Pcache TAG IPR Address 


31 25 24 23 22 21 13 12 11 05 04 00 


SBZ 1] 1,0 SBZ 8 Pcache Index Address SBZ 


Where B = 0-» Select the Left Bank of the Specified Index 
1 -» Select the Right Bank of the Specified Index 


Pcache Date Parity IPR Address 


31 25 24 23 22 21 13 12 11 05 04 03 02 00 


SBZ SBZ | Pcache index Address 


Where B = 0-» Select the Left Bank of the Specified Index 
1 -» Select the Right Bank of the Specified Index 


SBA = Sublock Address Selection aye 


The tag parity bit is included in the Pcache tag IPR format to allow the user to 
write bad tag parity into the array in order to verify the tag parity logic. Further, 
the valid bits and allocation bit are also included so that the Pcache can be 
initialized to a known state. 


The Pcache data parity allows the Pcache data parity to be directly read and 
written for testability purposes. 


4.4 Backup Cache 


The following sections describe the organization and operation of the backup 
cache. 
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4.4.1 Write-back Cache and Ownership Concepts 


There is one fundamental difference between a write-back cache, such as the 
Beache, and a write-through cache, such as the Pcache. When a write is received 
by a write-through cache, the data may or may not be written into the cache, but 
is always written to memory. When a write is received by a write-back cache, the 
write is not necessarily forwarded to memory; the write may be done only into the 
cache. The data is written back to memory only if another element in the system 
needs that data, or if the block is displaced (deallocated) from the cache. 


The NVAX backup cache is a write-back design in which a cache block may exist 
in one of three states: invalid, valid-unowned, and valid-owned. A block that is 
valid-unowned is a read-only copy of memory data. A block that is valid-owned 
may be written by NVAX, and if it has been written since being put into the 
cache, is the only up-to-date copy of the data in the system. The NVAX cache 
makes no distinction between valid-owned blocks it has written and those it has 
not written. 


The KA680 system supports the concept of memory ownership by implementing 
an ownership bit for every hexaword of main memory. When this memory 
receives an ownership read (OREAD) for a hexaword (due to a Bcache write miss 
or for VAX interlocked instructions), ownership is passed to the NVAX as the 
data is returned from the memory subsystem. If another read request arrives for 
that hexaword from a DMA device, memory does not return the data since the 
hexaword is not owned by memory but by the NVAX. The NVAX CPU recognizes 
the second read request as a cache coherence transaction and writes back the 
data from its cache, using the Disown Write (WDISOWN) command. The memory 
subsystem will then forward the data to the requesting DMA device. 


During write operations, the NVAX CPU issues an OREAD to the memory 
subsystem and receives ownership for blocks that miss in the Beache. After 
gaining ownership of the hexaword and allocating it into the Bcache, the 

NVAX CPU performs the desired write to that block in the backup cache. 

The NVAX CPU relinquishes ownership of the data by performing a WDISOWN 
write-back of the block when it sees an access to that hexaword on the NDAL bus 
from a DMA device. 


4.4.2 Backup Cache Overview 


The backup cache (Bcache) is direct-mapped, with quadword access size and a 
hexaword (32 bytes) block size. The Bcache allocates on reads and writes, and 
uses a write-back protocol. Bcache tags and cache data are stored in static RAMs 
that reside on the CPU module. The NVAX CPU implements the control for the 
Bcache tags and data. 


The Bcache and Pcache communicate internally to the NVAX CPU in such a 
way as to maintain the Pcache as a strict subset of the Bcache. This is done 
through the use of "invalidate" commands sent automatically from the Bceache 
to the Pcache whenever the Bceache must invalidate a block. The Bcache will 
invalidate a block in response to DMA activity to the corresponding memory 
location, or to make room in the cache for new data. In the case of Bcache 
blocks that contain data for NVAX-owned memory locations, the process of 
invalidating the block involves a write-back of the data contained in the cache 
to the corresponding memory location. The write-back operation simultaneously 
relinquishes ownership of the hexaword. 


The flow of memory transactions within the NVAX CPU is as follows: 
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I-stream read requests generated within the NVAX are first issued to the VIC. 

If the data is found there, then the request is satisfied. If the request misses in 
the VIC, then the request is forwarded to the Pcache. Since the VIC stores only 
I-stream data, all D-stream requests bypass the VIC and start at the Pcache. If 
the request hits in the Pceache, then the NVAX uses this data. Otherwise, the 
request is forwarded to the Beache. If the read request hits in the Bcache, then 
the NVAX uses this data and simultaneously copies it into the Pcache to speed up 
future references to this data. If the request misses in the Bcache as well, then 
an IREAD or DREAD cycle is issued to the memory subsystem on the NDAL bus. 
When the data comes back from the memory subsystem, the Pcache, Bcache, and 
possibly the VIC each allocate a block and fill it with this data. Note that the 
VIC caches only I-stream data. Likewise, reads that hit in the Bcache will also 
cause fills in the Pcache, and if I-stream, the VIC as well. 


Normal (that is, not disown writes) write transactions generated within the 
NVAX CPU cause cache lookups in the Peache and Beache. If the location to be 
written is found in the Bcache and is marked in the Bcache as owned by the 
NVAX CPU, then the write transaction will update only the Beache and Pcache 
entries and will not be sent to the memory subsystem. Note that on writes, 

the Pcache is updated only if the referenced location was already cached in the 
Pcache. 


If the location to be written is cacheable but is not currently cached in the 
Bcache, or is cached but not marked as owned by the NVAX CPU, then 
the NVAX CPU will issue an OREAD on the NDAL bus to gain ownership of 
the location. When the memory subsystem returns the data corresponding to 
the OREAD, the NVAX CPU will allocate a block in the Bcache if necessary, 

and will set the corresponding ownership bit in the Bcache. The setting of this 
ownership bit in the Bcache indicates to the NVAX CPU that it may freely update 
the contents of the cache without compromising the consistency of memory. The 
write transaction that initially caused the OREAD then completes, updating only 
the Bcache and Pcache entries. Since the data is now owned by the NVAX CPU, 
subsequent writes to that location will not result in NDAL cycles, since the data 
is only updated in the cache. The resulting speedup of write transactions and 
the conservation of NDAL bus bandwidth are the primary reasons for using the 
write-back algorithm in the Bceache. Note that under normal conditions, the 
memory ownership mechanism and the write-back nature of the Bcache is totally 
transparent to software. 


4.4.3 Backup Cache Operating Modes 


The backup cache has four distinct modes of operation. 
¢ Cache on. Normal operation. 


¢ Cache off. Reset puts the backup cache into the OFF state. The backup cache 
may be enabled/disabled (turned ON/OFF) by software through the Backup 
Cache Control IPR. Cache off mode is described in Section 4.4.13.1. 


¢ Force hit. This forces all memory space reads and writes forwarded to the 
Bcache to hit in the Bcache. This mode is used for testing and initialization 
purposes. Force hit mode is described in Section 4.4.13.2. 


e Error transition mode. The Beache enters error transition mode (ETM) upon 
recognition of some error conditions or when put into ETM explicitly by an 
IPR write. Error transition mode is described in Section 4.4.13.3. 
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4.4.4 NVAX Backup Cache Organization and Interface 


The NVAX backup cache is configurable based on the size and speed of the 
cache RAMs used to implement the cache on the board. Because of this, the 
configuration register must be written with the appropriate information based on 
the size and speed of the Bcache RAM chips used on the KA680. This function is 
performed by the console firmware. 


The KA680 has a 128 kilobyte Bcache. The NVAX CPU provides a control register 
by which it can be configured with the size of the Bcache. This is controlled by 
the SIZE field in the CCTL register, as described in Section 4.4.8.1. Firmware 
configures the NVAX CPU to operate with the amount of Bcache memory provided 
on the module. 


Table 4-11 Backup Cache Size and RAMs Used 


Valid Bits 
Cache Size Tag RAM Size Data RAM Size Number of Tags Per Tag 
128 kilobytes 4K x4 16K x 4 4K 1 


The cache has a block size of 32 bytes and has no subblocks. The data bus to the 
cache is 8 bytes wide, so in order to read out an entire block, 4 accesses are done. 
Each block contains 32 bytes of data and has associated with it a tag, a valid bit, 
and an owned bit. ECC protection is provided on each quadword in the cache. 
ECC protection is also provided on the tag store. 


Each address bit serves either as an index bit or as a tag bit. Table 4-12 shows 
how the bits are used. 


Table 4-12 Tag and Index Interpretation Based on Cache Size 
Cache Size Tag Bits Used Index Bits Used 


128 kilobytes Tag<28:17> Index<16:5> 


Note that bits <31:29> are "don’t cares" with respect to the mapping of tags and 
index bits because the KA680 is operated with the NVAX CPU in 30-bit address 
mode. 


Bit <29> is a "don’t care" because cacheable references always have bit <29>=0. 
For example, they are always in VAX memory space. With the NVAX CPU in 
30-bit mode, Bit <29>=1 indicates I/O space references, which are not cacheable. 


The NVAX CPU also requires software to program the backup cache speed as 
dictated by the speed of the RAM chips used on the board. The TAG_SPEED and 
DATA_SPEED fields of the Beache control register, CCTL, are used to control the 
number of NVAX cycles used by the Cbox to access the RAMs. These bit fields 
are written by firmware with the values appropriate to the module configuration. 
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4.4.5 Backup Cache Block Diagrams 


Figure 4-15 and Figure 4-16 show the connections to the tag store and data 
RAMs, and the way the address is used for the 128-kilobyte cache used on the 
KA680. 


Figure 4-15 Tags and Data for 128-Kilobyte Cache 


Tag Index<16:5> 


TAG STORE 


S PARTS, 4Kx4 


Valid Bit Owned Bit ECC<5:0> Tag<28:17> 


Data Index<16:3> 
DATA STORE 


18 PARTS, 16Kx4 (128KB) 


ECC<7:0> Data<63:00> 


Figure 4-16 Address Used for 128-Kilobyte Cache 


31 30 29 28 19 18 05 04 03 02 


xxx] Tag-12 Bits Data and Tag Store Index-12 Bits mr 


Used to Address Data Quadword Within Hexword 
Unused for Tag Store 
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4.4.6 Backup Cache Data Block Allocation 


4.4.6.1 Read References 
On cacheable read references that are not in the Peache, the request is forwarded 
to the Bcache internally to the NVAX CPU. If the requested quadword cannot be 
found in the Bcache, a read request is sent from the NVAX CPU to the memory 
subsystem. The length of the request is a hexaword, which is the same size as 
the Bceache and Pcache block size. Before the request is sent, however, the Bcache 
and Pcache each allocate a block for the new data. When the data returns from 
memory, copies are made in both the Bcache and Pcache to reduce latency on 
future references. Note that if the Bcache block being displaced by the new data 
is valid and has its owned bit set, then the displaced block will be written back 
to memory via a disown write transaction on the NDAL bus before the read for 
the cache fill is issued. This updates the displaced hexaword in memory with 
the possibly modified cached copy, and relinquishes ownership of that hexaword 
location. Since the Bcache is direct-mapped, that is, it has only one bank, there is 
no need to decide which bank to allocate for the fill. 


4.4.6.2 Write References 
The Bcache performs allocates on writes. Write references to cacheable memory 
locations do not propagate directly out to memory unless the Bcache has 
been disabled by clearing CCTL<ENABLE>. If the hexaword being written is 
contained in the Bcache and is owned by the NVAX CPU, then the write is done 
only to the Beache entry. If the referenced hexaword is not in the Bcache, or if 
it is in the Bcache but is not owned by the NVAX CPU, then ownership of the 
hexaword will be obtained by issuing an ownership read on the NDAL bus to the 
memory subsystem. Once ownership has been obtained, the write will proceed as 
described above, updating only the Bcache. 


Write references will update the Pcache only if the reference is already cached 
there. The Pcache does not perform allocations on writes. 


4.4.7 Effects of I/O Traffic on the Backup Cache 


In the following paragraphs, the term "DMA device" or "DMA traffic" refer to the 
Q22-bus, DSSI bus, or Ethernet interfaces. 


The NVAX CPU monitors all DMA traffic to main memory. For each reference, 
the NVAX CPU will check the contents of the backup cache to see if it contains 
the hexaword being referenced. If the referenced hexaword is not in the Bcache, 
then the NVAX CPU takes no further action. If, however, the referenced 
hexaword is currently cached, the specific actions taken thereafter depend on 
the type of DMA reference and whether the referenced hexaword is owned by the 
NVAX CPU. 


If the Bceache contains the hexaword referenced by the I/O device, but the Bcache 
block is not marked as "owned," then the NVAX CPU will invalidate the Bcache 
entry only if the DMA reference was a write. Note that in this case the Pcache 
is also checked for the referenced hexaword, and the appropriate Pcache block 

is invalidated if found. No cache entries are invalidated due to reads from DMA 
devices. 


If the Bceache contains the hexaword referenced by the I/O device, and the Bcache 
block is marked as "owned," then two things happen. First, when the reference 
from the DMA device is received by the memory subsystem, the reference will 

be pended in the NMC memory controller because the referenced hexaword is 
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not currently owned by the memory subsystem. Simultaneously, the NVAX CPU 
determines that it owns the hexaword referenced by the DMA device, and will 
write back the Bcache block to memory using an ndal disown write transaction 
(WDISOWN), relinquishing ownership of the hexaword in the process. The 
memory controller will respond to the disown write by updating the contents of 
main memory with the value from the Bcache, then allowing the DMA reference 
to complete. 

4.4.8 Backup Cache Internal Processor Registers 


The Bcache processor registers that are implemented by the NVAX CPU are 
logically divided into three groups, as follows: 


¢ Normal—Those IPRs that address individual registers in the NVAX CPU chip 
or system environment. 


¢ Bcache tag IPRs—The read-write block of IPRs that allow direct access to the 
Beache tags. 


¢ Bcache deallocate IPRs—The write-only block of IPRs by which a Bcache 
block may be deallocated. 


Each group of IPRs is distinguished by a particular pattern of bits in the IPR 
address, as shown in Figure 4-17. 


Figure 4-17 IPR Address Space Decoding as Seen by Software 
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The numeric range for each of the three groups is shown in Table 4-13. 


Table 4-13 IPR Address Space Decoding - KA680 
IPR Address Range 


IPR Group Mnemonic’ (hex) Contents 
Normal - 00000000..000000FF 256 individual IPRs 
Bcache Tag BCTAG 01000000..0101FFE0? 4K Beache tag IPRs, each 


separated by 20(hex) from the 
previous one 

Bcache Deallocate BCFLUSH 01400000..0141FFEO” 4K Bcache tag deallocate IPRs, 
each separated by 20(hex) 
from the previous one 


lThe mnemonic is for the first IPR in the block. 


?Unused fields in the IPR addresses for these groups should be zero. Neither hardware nor microcode 
detects and faults on an address in which these bits are nonzero, and they are ignored with respect to 
the tag or data location that is accessed. 
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Because of the sparse addressing used for IPRs in groups other than the normal 
group, valid IPR addresses are not separated by one. Rather, valid IPR addresses 
are separated by 20(hex). For example, the IPR address for Bcache tag 0 is 
01000000 (hex), and the IPR address for Bcache tag 1 is 01000020 (hex). In 
this group, bits <4:0> of the IPR address are ignored, so IPR numbers 01000001 
through 0100001F all address Beache tag 0. 


Processor registers in all groups except the normal group are processed entirely 
by the NVAX CPU chip and will never appear on the NDAL. This is also true for 
a number of the IPRs in the normal group. IPRs in the normal group that are 
not processed by the NVAX CPU chip are converted into I/O space references and 
passed to the system environment via a Read or Write command on the NDAL. 


The Bcache processor registers implemented by the NVAX CPU are are shown in 
Table 4-15. 


Table 4-15 Bcache/NDAL Processor Registers 


Number 


Register Name Mnemonic (Dec) (Hex) Type Impl Cat 


Bcache Control Register CCTL 160 AO RW NVAX 2-5 
Reserved for NVAX - 161 Al - NVAX 2-6 
Bcache Data ECC BCDECC 162 A2 W NVAX 2-5 
Beache Error Tag Status BCETSTS 163 A3 RW NVAX 2-5 
Bceache Error Tag Index BCETIDX 164 A4 R NVAX 2-5 
Beache Error Tag BCETAG 165 A5' R NVAX 2-5 
Beache Error Data Status BCEDSTS 166 A6é RW NVAX 2-5 
Beache Error Data Index BCEDIDX 167 A7 R NVAX 2-5 
Bceache Error Data ECC BCEDECC 168 A8& R NVAX 2-5 
Reserved for NVAX - 169 AQ - NVAX 2-6 
Reserved for NVAX - 170 AA —- NVAX 2-6 
Fill Error Address CEFADR 171 AB R NVAX 2-5 
Fill Error Status CEFSTS 172 AC RW NVAX 2-5 
Reserved for NVAX - 173 AD - NVAX 2-6 
NDAL Error Status NESTS 174 AE RW NVAX 2-5 
Reserved for NVAX - 175 AF - NVAX 2-6 
NDAL Error Output Address NEOADR 176 BO R NVAX 2-5 
Reserved for NVAX - 177 Bl - NVAX 2-6 
NDAL Error Output Command NEOCMD 178 B2 R NVAX 2-5 
Reserved for NVAX - 179 B3 - NVAX 2-6 
NDAL Error Data High NEDATHI 180 B4 R NVAX 2-5 
Reserved for NVAX - 181 BSB - NVAX 2-6 
NDAL Error Data Low NEDATLO 182 B6 R NVAX 2-5 
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Table 4-15 Bcache/NDAL Processor Registers 


Number 
Register Name Mnemonic (Dec) (Hex) Type Impl Cat 
Reserved for NVAX - 183 BT - NVAX 2-6 
NDAL Error Input Command NEICMD 184 B8 R NVAX 2-5 
Reserved for NVAX - 185 BO - NVAX 2-6 
Reserved for NVAX - 186 BA - NVAX 2-6 
Reserved for NVAX - 187 BB -—- NVAX 2-6 
Reserved for NVAX - 188 BC - NVAX 2-6 
Reserved for NVAX - 189 BD —- NVAX 2-6 
Reserved for NVAX - 199 BE —- NVAX 2-6 
Reserved for NVAX - 191 BF —- NVAX 2-6 
Bcache Tag-KA680 (01000000 - 0101FFE0O HEX) BCTAG - - RW NVAX 2-5 
Bcache Deallocate-KA680 (01400000 - 0141FFEO =BCFLUSH - - WwW NVAX 2-5 


HEX) 


If a write-only NVAX processor register is read, the Cbox returns 
UNPREDICTABLE data. Reading an unimplemented NVAX processor register 
returns UNPREDICTABLE data; if an unimplemented register is written, the 
write is discarded and normal operation continues. 


If software attempts to access an IPR, specifying an address that is not within the 
NVAX block of IPR addresses, the reference will be converted to an I/O space read 
or write. In this case, the NVAX merges the IPR address with E1000000 hex, 
effectively adding the base I/O space address of the IPR block to the IPR address. 
This is done in hardware by forcing bits <31:29> and bit <24> to 1s. (The other 
upper bits are expected to be received as Os.) 


From this point on, the transaction is treated as an I/O space transaction by the 
NVAX. It sends the request off-chip to the NDAL. When the data returns, it is not 
cached by the NVAX. I/O space reads and writes are never cached in the primary 
cache or the backup cache. 
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4.4.8.1. Bcache Control IPR (CCTL) 


CCTL is a read/write register that contains bits controlling the behavior of 
the Beache and related portions of the NVAX CPU. The bits are detailed in 
Figure 4-18 and Table 4-16. 


Figure 4-18 IPR Format of CCTL 
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Table 4-16 CCTL 


Name Extent Type Description 

ENABLE 0 RW,0 Turns the Bcache on and off. 

TAG_SPEED 1 RW,0 Controls time NVAX allows to access the 
tag RAMs. 

DATA_SPEED 3:2 RW,0 Controls time NVAX allows to access the 
data RAMs. 

SIZE 5:4 RW,0 Selects between backup cache sizes. 

FORCE_HIT 6 RW,0 Forces memory reads and writes to hit 
in the backup cache. 

DISABLE_ERRORS 7 RW,0 Disables all backup cache ECC errors. 

SW_ECC 8 RW,0 Enables use of ECC check bits as given 
by software for the tag and data. 

TIMEOUT_TEST 9 RW,0 Puts the NDAL read timeout timers into 
test mode. 

DISABLE_PACK 10 RW,0 Disables the write packer. 

FORCE_NDAL_PERR 16 RW,0 Forces a parity error in the command 
field of the next outgoing NDAL 
transaction. 

SW_ETM 30 RW Used by software to put the backup 
cache into ETM. 

HW_ETM 31 WC Used by hardware to put the backup 


cache into ETM. 


ENABLE 


When ENABLE=1, the backup cache is enabled for operation. When ENABLE=0, 
the backup cache is off and all references are treated as misses and are not looked 
up in the backup cache. When the backup cache is off, FORCE_HIT, SW_ETM, 
and HW_ETM are ignored. System reset clears this bit so that the Bcache is off 
when the chip is reset. 


TAG_SPEED 


The NVAX provides this bit to configure the NVAX to function properly with 
Bceache tag RAM chips of various speeds. This bit will select the mode of Bcache 
operation that corresponds to the speed of the RAM chips used on the module. 


Note 


Improper setting of these bits can prevent the NVAX CPU from 
functioning properly. 


This bit is cleared on system reset and should not be set to a value other than 
that recommended in Table 4-17. Table 4-17 shows the relationship of the value 
of TAG_SPEED and the access time of the tag RAMs, given in NVAX cycles. This 
is the total RAM access time including internal NVAX processing time. Reset 
clears this bit so that the tag access repetition rate is 3 cycles when the chip is 
reset. See Appendix J. 
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Table 4-17 TAG_SPEED 


Tag Read Tag Write 
TAG_SPEED (rep rate) (rep rate) Comments 
0 3 Cycles 3 Cycles - 
1 4 Cycles 4 Cycles May not be used when DATA_ 


SPEED=00 


DATA_SPEED 


The NVAX provides this bit to configure the NVAX to function properly with 
Bceache data RAM chips of various speeds. This bit will select the mode of Bcache 
operation that corresponds to the speed of the Bcache data RAM chips used on 
the module. 


Note 


Improper setting of this bit can prevent the NVAX CPU from functioning 
properly. 


This bit is cleared on system reset and should not be set to a value other than 
that recommended in Table 4-17. Table 4-18 shows the relationship of the value 
of DATA_SPEED and the access time of the DATA RAMs, given in NVAX cycles. 
This is the total RAM access time including internal NVAX processing time. 
Reset clears this bit so that the Bcache data access repetition rate is 2 cycles 
when the chip is reset. 


Table 4-18 DATA_SPEED 


Data Read Data Write 
DATA_SPEED<1:0> (rep rate) (rep rate) Comments 
00 2 Cycles 3 Cycles May not be used when 
TAG_SPEED=1 
01 3 Cycles 4 Cycles - 
10 4 Cycles 5 Cycles - 
11 Unused Unused - 


SIZE 


These two bits are used to program the size of the Bcache. Backup cache size 
is programmed by using the SIZE bits, as shown in Table 4-19. These bits are 
cleared on reset so that when the chip is reset, the correct setting is selected by 
default. 


Note 


On the KA680, specifying any value other than that for the 128-kilobyte 
cache is strictly forbidden, because it will prevent operation. 
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Table 4-19 SIZE 


SIZE<1:0> Backup Cache Size 
00 128 kilobytes 
FORCE_HIT 


When FORCE_HIT is set, all memory references, both D-stream and I-stream 
reads and writes, are forced to hit in the backup cache. The tag store state is not 
changed but data is always read or written. Reset clears this bit. 


The backup cache must be enabled when the cache is used in FORCE_HIT mode. 


This mode provides the capability for directly accessing the Bcache data store, 
and is expected to be used for testing purposes only. 


DISABLE_ERRORS 

When DISABLE_ERRORS is set, all ECC errors from the backup cache are 
ignored. The backup cache data syndrome is loaded into the BCEDECC IPR on 
every cache access; the behavior of BCETSTS, BCETIDX, BCETAG, BCEDSTS, 
and BCEDIDX is unpredictable. This feature allows operation of the backup 
cache even if the error detection and correction logic is faulty. It also allows 
access to the backup cache syndrome for the purposes of testing the ECC logic. 
Reset clears this bit. 


SW_ECC 

When SW_ECC is clear, the NVAX CPU generates correct ECC check bits for all 
writes to the tag store and data RAMs. When SW_ECC is set, the NVAX does not 
generate the check bits when the backup cache is written with data, but uses the 
check bit values as specified by software in the BCDECC register. 


When SW_ECC is set and the tag store is written using an IPR write to BCTAG, 
the NVAX uses the check bits for the tag store as given through the IPR write. 
The value of SW_ECC does not affect tag store transactions other than IPR 
writes. 


Reset clears this bit. 


TIMEOUT_TEST 

When TIMEOUT_TEST is set, the NVAX uses the internal clock to clock its read 
timeout counter. When TIMEOUT_TEST is clear, the NVAX uses an internal 
time base clock its timeout counters. Reset clears this bit. The effect of setting 
this bit is to cause reads on the NDAL to timeout much sooner than they would if 
this bit were clear. This is useful primarily for testing purposes. This bit should 
not be set during normal operation. 


DISABLE_PACK 


The NVAX normally packs consecutive memory space writes to the same 
quadword into one write, thereby saving Bcache or NDAL bus bandwidth, 
depending on whether the referenced hexaword is cached. When DISABLE_ 
PACK is set, the NVAX does not pack quadword writes together. Instead, the 
write packing logic inside the NVAX CPU passes every write directly to its 
destination: either the Bcache or the memory subsystem. When the bit is clear, 
the NVAX packs writes together to maximize performance. DISABLE_PACK is 
intended for testing purposes only. Reset clears this bit. 
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FORCE_NDAL_PERR 


When a 1 is written to FORCE_NDAL_PERR, a parity error is caused in the 
command field of the next outgoing NDAL transaction. Setting this bit causes 
only one parity error. Another parity error will be produced with the bit is cleared 
and set again by software. 


Reset clears this bit. 


SW_ETM 


This is a software-writable bit to put the backup cache into error transition mode. 
When the cache is on and software ascertains that the cache is producing errors, 
it can set this bit in order to turn off the cache while ensuring cache coherency. 
Software can then flush owned data through use of the Bceache deallocate IPR, 
BCFLUSH. In this manner, the unique data can be extracted from the cache 
before it is turned off completely. 


HW_ETM 


Hardware sets this bit when an uncorrectable error is detected in the backup 
cache tag store or data RAMs, unless DISABLE_ERRORS is set. Hardware sets 
the bit to put the backup cache into error transition mode. 


Software clears HW_ETM by writing a 1 to it. 
4.4.8.2 Backup Cache Data ECC IPR (BCDECC) 


Figure 4-19 Format of the BCDECC 
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The ECCHI field corresponds to data check bits <7:4>. The ECCLO field 
corresponds to data check bits <3:0>. 


This register is written by software. It is a write-only register. 


Software writes BCDECC using an MTPR instruction. The value in the register 
is then used to explicitly write ECC into the data RAMs during any write of the 
data RAMs, but only if SW_ECC is set in the control register. If SW_ECC is not 
set, hardware ignores the value in BCDECC and generates the check bits to be 
written using the ECC syndrome generator. 


One use of BCDECC is to allow software to explicitly write bad ECC into the data 
RAMs in order to test the Beache error detection logic. 


Reset does not affect this register. 
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4.4.8.3 Backup Cache Tag Store Error Registers (BCETSTS, BCETIDX, BCETAG) 
On some tag store errors, hardware overwrites the corrupted values so that they 
cannot be diagnosed by reading the tag store directly. For this reason, there 
are tag store error registers that hold the relevant data so that software can 
understand the problem. 


The tag store error registers are loaded when any tag store error occurs. The 
status bits in BCETSTS indicate what sort of error happened. Correctable errors 
are indicated by the CORR bit; the UNCORR and BAD_ADDR errors are both 
uncorrectable errors. 


If no error is yet logged in the registers, the registers are loaded when either a 
correctable or an uncorrectable error occurs. Once the registers are loaded with 
information from a correctable error, they are locked against further correctable 
errors, and are only loaded again if an uncorrectable error happens. At this time, 
either UNCORR or BAD_ADDR is set. The LOCK bit in BCETSTS is set as well. 
In this way, information from the first correctable error is held in the registers, 
and is only overwritten if an uncorrectable error happens later. 


The error registers are cleared and unlocked by software. If the error registers 
hold data from a noncorrectable error and yet another noncorrectable error 
happens before the error registers are unlocked, the LOST_ERR bit is set. This 
indicates to software that it does not have sufficient information in the error 
registers to recover from all uncorrectable errors that have occurred. 


4.4.8.3.1_ Bceache Error Tag Status (BCETSTS) The BCETSTS register gives 
the general status of an error in the tag store, indicating the transaction taking 
place at the time and the type of error. The register is written by hardware and 
read by software. Hardware does not clear the error bits in this register; this 
must be done by software using write-one-to-clear to the bottom five bits of the 
register. 


Figure 4-20 IPR Format of BCETSTS 
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Table 4-20 Bcache Tag Store Status IPR Format 


Name Extent Type Description 

LOCK 0 WC Indicates that BCETSTS, BCETIDX, 
and BCETAG are locked. 

CORR 1 WC Indicates that a correctable ECC error 
was encountered. 

UNCORR 2 WC Indicates that an uncorrectable ECC 
error was encountered. 

BAD_ADDR 3 WC Indicates that an addressing error was 
detected. This is an uncorrectable error. 

LOST_ERR 4 WC Indicates that more than one 


uncorrectable error occurred, which 
was not recorded in the error registers. 


TS_CMD 9:5 R Indicates what tag store command was 
being processed at the time the error 
occurred. 

LOCK 


Whenever the tag store error registers are locked due to an uncorrectable error, 
the LOCK bit is set. At this time, either UNCORR or BAD_ADDR is also set to 
indicate the type of uncorrectable error. When the LOCK bit is set, the BCETSTS, 
BCETIDX, and BCETAG registers are all locked. Clearing the lock bit unlocks all 
three registers. The LOCK bit is set by hardware and it is cleared by software. It 
is a write-one-to-clear bit. 


CORR 

CORR is set when the tag store ECC decoder detects a correctable error. When 
this occurs, the Bcache tag store error registers are loaded and are locked against 
further correctable errors. They are not locked against an uncorrectable error 
that follows. 


If a correctable error is followed by an uncorrectable error, the CORR bit remains 
set. 


The CORR bit is set by hardware and it is cleared by software. It is a write-one- 
to-clear bit. 


UNCORR 


UNCORR is set when the tag store ECC decoder detects an uncorrectable error. 
When this occurs, the Bcache tag store error registers are loaded and locked. 


The UNCORR bit and the BAD_ADDR bit are exclusive: only one of them is set 
for a given error that sets the LOCK bit. If the other type of error occurs later, 
the related bit is not set since the register is already locked. In this case, LOST_ 
ERR is set instead. 


The UNCORR bit is set by hardware and it is cleared by software. It is a write- 
one-to-clear bit. 


BAD ADDR 

BAD_ADDR is set when the tag store ECC decoder detects an error in the address 
bit, indicating some problem with the address lines going to the tag RAMs. This 
is an uncorrectable error; thus, when it occurs, the Bcache Tag Store Error 
registers are loaded and locked. 
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The UNCORR bit and the BAD_ADDR bit are exclusive: only one of them is set 
for a given error that sets the LOCK bit. If the other type of error occurs later, 
the related bit is not set since the register is already locked. In this case, LOST_ 
ERR is set instead. 


The BAD_ADDR bit is set by hardware and it is cleared by software. It is a 
write-one-to-clear bit. 
LOST_ERR 


LOST_ERR indicates that after the first uncorrectable error was recorded in the 
tag store error registers, an additional uncorrectable error occurred for which 
state was not saved. LOST_ERR is set by hardware and is cleared by software. 
It is a write-one-to-clear bit. 


TS_CMD 


The five bit field, TS_CMD, indicates what the tag store was doing when the error 
was detected. Its values are listed in Table 4—21. 


Table 4-21 Interpretation of TS_CMD 


TS_CMD Name Tag Store Operation 

00111 DREAD Data-stream tag lookup 

00011 IREAD Instruction-stream tag lookup 

00010 OREAD Ownership-read tag lookup for a write or a READ_ 
LOCK 

01000 WUNLOCK Ownership-read tag lookup for a WRITE_UNLOCK 

01101 R_INVAL Cache coherency tag lookup as the result of NDAL 
DREAD or IREAD 

01001 O_INVAL Cache coherency tag lookup as the result of NDAL 
OREAD or WRITE 

01010 IPR_DEALLOC _ Tag lookup for an explicit IPR deallocate operation 


There are three tag store operations that do not cause any sort of errors: tag 
store update after a fill, IPR write of the tag store, and IPR read of the tag store. 
Thus, these commands will not appear in BCETSTS. 


4.4.8.3.2_ Bcache Error Tag Index (BCETIDX) This register is loaded and locked 
when a tag store error occurs. If a correctable error is followed by a second error 
that is not correctable, the register is loaded with information from the second, 
more serious error. Except for this case, once it is locked, it is not changed until 
software explicitly unlocks the register. This register is written by hardware and 
read by software. 


Figure 4—21 Backup Tag Store Error Address IPR 
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BCETIDX contains the complete hexaword address corresponding to a tag store 
request that resulted in an error. Since the full address is saved, both the cache 
index and the cache tag of the request are known. Thus, this register shows what 
index was being accessed when the error occurred as well as showing what the 
tag of the request was. Software can compare this tag with the actual tag read 
from the RAMs, which is saved in BCETAG. 


4.4.8.3.3. Beache Error Tag (BCETAG) This register is loaded when a tag store 
error occurs. It is locked when an uncorrectable error occurs on a tag store access. 
Once the register is locked, it is not overwritten until it is unlocked by software. 
BCETAG is written by hardware and read by software. It is a read-only register 
from the software point of view. 


The register holds the data that was read from the tag store and produced the 
error, as shown in Figure 4—22. 


Figure 4-22 IPR Format of BCETAG 
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Table 4-22 BCETAG IPR Format 
Name Extent Type Description 
VALID 9 RO Valid bit 
OWNED 10 RO Ownership bit 
ECC 16:11 RO ECC check bits 
TAG 31:17 RO Backup cache tag 


VALID 

VALID is the bit read from the tag RAMs, which indicates whether the block is 
valid in the Bcache. 

OWNED 


OWNED is the bit read from the tag RAMs, which indicates whether the Bcache 
(NVAX) owns the memory hexaword contained in this Beache block. 


ECC 

The ECC field contains the check bits as read from the tag RAMs during the 
tag access that produced the error. The code used for tag ECC is shown in 
Figure 4—23. The check bit marked with a "1" in each row is generated by a 
parity tree whose inputs are the Tag, Valid, Owned, and AP (address parity) bits, 
which are marked with a "1" in that row. 


4-36 KA680 Cache Memory Overview 


KA680 Cache Memory Overview 
4.4 Backup Cache 


Figure 4—23 Tag Store Error Correcting Code Matrix 
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In a tag store read operation, a nonzero syndrome indicates an error. If the 
syndrome generated matches one of the columns in the matrix, the error is 
correctable and the matching column indicates the bit to be corrected. Any 
syndrome value that is nonzero and does not match a column in the matrix 
indicates an uncorrectable error. 


Odd parity is used for check bits 1 and 4 to protect against the all-zeros failure 
mode. Otherwise, all-zeros would be a valid code word. The choice of odd and 
even parity bits prevents all-ones from being a valid code word as well. 


TAG 


The TAG field of BCETAG is the cache tag as read from the tag RAMs. It must 
be interpreted based on the cache size being used, as shown in Table 4-23. When 
certain address bits are not used as tag bits for the cache size given, their value 
in BCETAG is 0. 


Table 4-23 TAG Interpretation 
Cache Size Tag Bits Used Unused Tag Bits 
128 KB (KA680) TAG<28:17> TAG<31:29> 
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4.4.8.4 Backup Cache Data RAM Error Registers (BCEDSTS, BCEDIDX, BCEDECC) 


The data RAM error registers hold data relevant to errors in the backup cache 
data RAMs so that software can understand the problem. 


BCEDSTS holds the general status of the problem. BCEDIDX holds the data 
RAM index being used when the problem occurred. BCEDECC holds the 
syndrome bits as calculated on the data, which was read from the RAMs when 
the problem occurred. 


If no error is yet logged in the data RAM error registers, the registers are loaded 
when either a correctable or an uncorrectable error occurs. Once the registers are 
loaded with information from a correctable error, they are locked against further 
correctable errors, and are only loaded again if an uncorrectable error happens. 
If an uncorrectable error happens, the LOCK bit in BCEDSTS is set and the 
registers are not overwritten until software clears the error bits. In this way, 
information from the first correctable error is held in the registers, and is only 
overwritten if an uncorrectable error happens later. 


If the registers are locked, any subsequent noncorrectable error causes the LOST_ 
ERR bit to be set, but does not modify any other information in the registers. 
LOST_ERR indicates to software that it does not have sufficient information in 
the error registers to recover from all uncorrectable errors that have occurred. 


Of the backup cache data RAM error registers, only BCEDSTS is writable by 
software. Software clears the error and LOCK bits, which re-enables all the data 
RAM error registers to record the next error that occurs. 


4.4.8.5 Bcache Error Data Status (BCEDSTS) 


Figure 4-24 IPR Format of BCEDSTS 
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Table 4-24 Bcache Data RAM Status IPR Format 


Name Extent Type Description 

LOCK 0 WC Lock bit. Indicates that the BCEDSTS, 
BCEDIDX, and BCEDECC registers are 
locked. 

CORR 1 WC Indicates that a correctable ECC error 
was encountered. 

UNCORR 2 WC Indicates that an uncorrectable ECC 
error was encountered. 

BAD_ADDR 3 WC Indicates that an addressing error was 
detected. 

LOST_ERR 4 WC Indicates that a second, uncorrectable 


error occurred; it was not recorded in the 
error registers. 


DR_CMD 11:8 R Indicates what command was being 
processed at the time the error occurred. 


The LOCK bit is set when an error that was not correctable has occurred. If the 
CORR bit is set, the data ram error registers are locked unless an uncorrectable 
error occurs. On an uncorrectable error, the LOCK bit is set and the registers are 
permanently locked until unlocked by software. 


LOCK 

Whenever the data RAM error registers are loaded with an uncorrectable error, 
the LOCK bit is set. At this time either UNCORR or BAD_ADDR is also set 
to indicate the type of uncorrectable error. When the LOCK bit is set, the 
BCEDSTS, BCEDIDX, and BCEDECC registers are all locked. Clearing the 
lock bit unlocks all three registers. The LOCK bit is set by hardware and it is 
cleared by software. It is a write-one-to-clear bit. 


CORR 


CORR is set when the data ECC decoder detects a correctable error. When this 
occurs, the Bceache data error registers are loaded and locked against further 
correctable errors. The CORR bit is set by hardware and it is cleared by software. 
It is a write-one-to-clear bit. 


UNCORR 


UNCORR is set when the data ECC decoder detects an uncorrectable error. When 
this occurs, the Bcache data error registers are loaded and locked. The UNCORR 
bit is set by hardware and it is cleared by software. It is a write-one-to-clear bit. 


BAD_ADDR 


BAD_ADDR is set when the data ECC decoder detects an error in the address bit, 
indicating some problem with the address lines going to the data RAMs. This is 
an uncorrectable error; thus, when it occurs, the Bceache data error registers are 
loaded and locked. The BAD_ADDR bit is set by hardware and it is cleared by 
software. It is a write-one-to-clear bit. 


LOST_ERR 


LOST_ERR indicates that after the first uncorrectable error was recorded in the 
data error registers, an additional uncorrectable error occurred for which state 
was not saved. LOST_ERR is set by hardware and is cleared by software. It is a 
write-one-to-clear bit. 
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DR_CMD 


The DR_CMD field indicates what the data RAMs were doing when the error was 
detected. Its values are listed in Table 4—25. 


Table 4-25 Interpretation of DR_CMD 


DR_CMD<11:7> Name Data RAM Operation 

0111 DREAD Data lookup for a D-stream read. 

0011 IREAD Data lookup for an I-stream read. 

0100 WBACK Data lookup for a write-back. 

0010 RMW Data lookup for a read-modify-write. Done for 


normal writes and WRITE_UNLOCKs. 


There are two data RAM operations that do not cause any sort of errors: full 
quadword writes and fills. Thus, these commands will not appear in BCEDSTS. 


DR_CMD is only written by hardware. It is read-only for software. 


4.4.8.5.1. Bcache Error Data Index (BCEDIDX) This register holds the index of 
a data RAM transaction; it is loaded when an error is detected on a data RAM 
access. The index loaded due to a correctable error is not overwritten unless an 
uncorrectable error occurs afterwards. If an uncorrectable error occurs, BCEDIDX 
is loaded and locked. BCEDIDX is unlocked by software; the LOCK bit is in the 
BCEDSTS register. 


BCEDIDxX is read-only from software’s point of view. 


Figure 4-25 BCEDIDX 
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BCEDIDX must be interpreted based on the cache size being used, as shown in 
Table 4-26. When certain address bits are not used as index bits for the cache 
size given, their value in BCEDIDX is undefined. 


Table 4-26 BCEDIDX Interpretation 


Cache Size Index Bits Used Undefined Index Bits 


128 KB (KA680) BCEDIDX<16:3> BCEDIDX<20:17> 
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4.4.8.6 Bcache Error Data ECC (BCEDECC) 


This register holds the syndrome as calculated on the backup cache data and 
check bits, and is loaded when an error occurs on a data RAM access. Once 
loaded, it follows the same lock rules that the other Bcache data error registers 
follow. It is unlocked by software. The lock bit is in the BCEDSTS register. 


When DISABLE_ERRORS is set, BCEDECC is loaded on every quadword read 
from the cache. This provides a way of testing the ECC logic by reading the 
results of the syndrome calculation. 


BCEDECC is read-only from software’s point of view. 


Figure 4-26 Format of the BCEDECC Register 
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The ECCHI field corresponds to syndrome bits <7:4>. The ECCLO field 
corresponds to syndrome bits <3:0>. 


The code used for data ECC is shown in Figure 4—27. The check bit (C), which is 
marked with a "1" in each row, is generated by a parity tree whose inputs are the 
data bits marked with a "1" in that row. 


Figure 4-27 Backup Cache Data Store Error Correcting Code Matrix 


DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD D DDD 
0123 4567 8911 1111 1111 2222 2222 2233 3333 3333 4444 4444 4455 5555 5555 6CCC CCCCC666 A 
01 2345 6789 0123 4567 8901 2345 6789 0123 4567 8901 2345 6789 0012 3456 7123 P 


1101 0001 0001 0011 1110 1101 1101 1100 0011 0010 0010 1101 1110 1010 1110 0100 0000 0000 1 SO 
1010 0010 0010 0100 1011 1010 1010 1011 0100 0100 0100 1011 1011 1101 1101 1010 0000 0000 1 S1 
0111 1100 1100 1000 0101 0111 0111 0111 1000 1001 1001 0110 0101 0111 0011 0001 0000 0000 1 S2 
0100 1111 1111 0001 0010 0001 0001 0001 0001 0001 0001 0001 1111 0001 1111 1000 1000 0100 0 S3 
1111. 0101 1001 0111 0001 0100 0100 1000 0111 1101 1101 0010 0110 1000 0110 0000 0100 0010 1 S4 
1111 1010 0110 1101 0100 1000 1000 0010 1101 1011 1011 0100 1001 0100 1001 0000 0010 0001 1 S5 
1011 1111 0000 0100 1000 1101 0010 0100 1011 1000 0111 0111 1111 1101 0000 1000 0001 0111 0 S6 
0000 1111 0000 1111 0000 1111 0000 0000 0000 1111 0000 1111 0000 1111 1111 0000 0000 1111 0 S7 


AP is not stored in the RAMS. 
Even parity - CO, C1, C2, C4, C5, C6 
Odd parity - C3, C7 
Sn = (Generated Cn) XOR (Stored Cn) 
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As in tag store ECC, any syndrome value not matching a column in the table 
indicates an uncorrectable error. Odd parity is used in check bits 3 and 7 to 
prevent all-ones and all-zeros from being valid code words. 


4.4.9 Fill Error Registers (CEFADR, CEFSTS) 


Some errors are related to outstanding reads to memory. These errors may be 
diagnosed using the CEFSTS and CEFADR registers. CEFSTS holds general 
information about the type of read outstanding; CEFADR holds the address of the 
outstanding read. 
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4.4.9.1. Beache Error Fill Status (CEFSTS) 


The CEFSTS register holds information related to a problem on a read that was 
sent to memory. If a read request to memory times out or is terminated with an 
error, the CEFSTS register and the CEFADR register are loaded and locked. 


The register is read-write. Only the lowest five bits may be written, and then 
only to clear them after an error. The lowest five bits are write-one-to-clear. 


Figure 4-28 IPR Format of CEFSTS 
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Table 4-27 Fill Error Status IPR Format 


Name Extent Type Description 

RDLK 0 WC Indicates that a READ_LOCK was in 
progress. 

LOCK 1 WC Indicates that an error occurred and 
the register is locked. 

TIMEOUT 2 WC Fill failed due to transaction timeout. 

RDE 3 WC Fill failed due to read data error. 

LOST_ERR 4 WC Indicates that more than one error 
related to fills occurred. 

IDO 5 RO NDAL identification bit for the read 
request. 

IREAD 6 RO This is an I-stream read from the 
Mbox, which may be aborted. 

OREAD 7 RO This is an outstanding OREAD. 

WRITE 8 RO This read was done for a write. 

TO_MBOX 9 RO Data is to be returned to the Mbox. 

RIP 10 RO READ invalidate pending. 

OIP 11 RO OREAD invalidate pending. 

DNF 12 RO Do not fill - data not to be written into 
the cache or validated when the fill 
returns. 

RDLK_FL_DONE 13 RO Indicates that the last fill for a READ_ 
LOCK arrived. 

REQ_FILL_DONE 14 RO Indicates that the requested quadword 
was successfully returned from the 
NDAL. 

COUNT 16:15 RO For a memory space transaction, 


indicates how many of the fill 
quadwords have been successfully 
returned. For I/O space, is set to 11 
when the transaction starts since only 
one quadword will be received. 


UNEXPECTED_FILL 21 RO Set to indicate that an unexpected fill 
was received on the NDAL. 


RDLK 


RDLK is set to show that a READ_LOCK is in progress. This bit is write-one-to- 
clear. 


The effect of performing a write-one-to-clear to this bit is to clear the VALID bit 
for an entry that had its RDLK bit set; this has the effect of clearing out the 
FILL_CAM entry. This is the same action taken when a WRITE_UNLOCK is 
received. 


This bit is normally not read as a one by software, because the NVAX microcode 
ensures that the READ_LOCK-WRITE_UNLOCK sequence is an indivisible 
operation. If, however, the first quadword of a READ_LOCK is returned 
successfully and then the transaction either times out or is terminated in read 
data error (RDE), CEFSTS is loaded with the RDLK bit set. 
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LOCK 


The LOCK bit is set when a read transaction that has been sent to memory 
terminates in read data error or in timeout. At the same time, all information 
corresponding to the read is loaded from the FILL_CAM into the CEFSTS 
register. When the LOCK bit is set, one of TIMEOUT, RDE, or UNEXPECTED _ 
FILL is also set to indicate the type of error. Once the LOCK bit is set, none of 
the information in CEFSTS or CEFADR changes, with the possible exception of 
LOST_ERR, until the LOCK bit is cleared. 


Hardware sets the LOCK bit and software clears it by writing a one to that 
location. 
TIMEOUT 


TIMEOUT is set when a read transaction that was sent to the NDAL times out 
for some reason. When TIMEOUT is set, the LOCK bit is also set. 


Hardware sets the TIMEOUT bit and software clears it by writing a one to that 
location. 
RDE 


RDE (read data error) is set when a read transaction that was sent to the NDAL 
terminates in RDE. This could happen because of an uncorrectable main memory 
error, or in the case of I/O addresses, it could mean some type of I/O error. When 
the RDE bit is set, the LOCK bit is also set. 


Hardware sets the RDE bit and software clears it by writing a one to that 
location. 
LOST_ERR 


The LOST_ERR bit is set when CEFSTS is already locked and another RDE, 
TIMEOUT, or UNEXPECTED_FILL error occurs. This indicates to software that 
multiple errors have happened and state has not been saved for every error. 


Hardware sets the LOST_ERR bit and software clears it by writing a one to that 
location. 

IDO 

IDO corresponds to the NDAL signal, ID_H, which was issued with the read that 
failed. According to NDAL protocol, the NVAX, as well as other NDAL devices, 
may have up to two outstanding transactions. Since memory reads are pended, 
the NVAX could have issued up to two read requests before the error occurred. 
This bit tells software which of the two NDAL transactions is associated with the 
error. 

IREAD 

IREAD indicates that the transaction in error was an IREAD. 


OREAD 

OREAD indicates that the transaction in error was an OREAD (ownership read); 
the OREAD may have been done for a write, a READ_LOCK, or a read modify. 
WRITE 

WRITE indicates that the transaction in error was an OREAD done because of a 
write request. 

TO_MBOX 


TO_MBOxX indicates that data returning for the read was to be sent to the Mbox. 
The Mbox is the part of the NVAX CPU that contains the virtual/physical address 
translation logic as well as the Pcache. 
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RIP 


RIP (read invalidate pending) is set when the NVAX observes a DMA read 
transaction on the NDAL to a memory location for which the NVAX is currently 
acquiring ownership (that is, the OREAD transaction has already been sent to 
the memory subsystem). This triggers a write-back of the block when the OREAD 
fill data arrives; a valid copy of the data is kept in the cache. 


OIP 


OIP (OREAD invalidate pending) is set when a cache coherency transaction due 
to an OREAD or a WRITE on the NDAL is requested for a block that has OREAD 
fills outstanding at the time. This triggers a write-back and invalidate of the 
block when the fill data arrives. 


DNF 


DNF (do not fill) is set when data for a read is not to be written into the Bcache. 
This is the case when the cache is off, in ETM, or when the read is to I/O space. 
The assertion of this bit prevents the block from being validated in the cache. 


RDLK_FL_DONE 


This bit is set in the fill cam when a READ LOCK hits in the Bcache or the last 
fill arrives from the BIU for a READ_LOCK. Once this is set, the corresponding 
WRITE_UNLOCK is allowed to proceed. This overrides the FILL_CAM block 
conflict on the WRITE_UNLOCK, which is inevitable since the READ_LOCK is 
held in the FILL_CAM until the WRITE_UNLOCK is done. 


REQ_FILL_DONE 


This bit is set when the requested quadword of data was successfully received 
from the NDAL. This information is provided to facilitate error handling. 


COUNT 


These two bits indicate how many of the expected four quadwords have been 
returned successfully from memory for this read. If they are 00(BIN), no 
quadwords have returned, if they are 01(BIN), one quadword has returned, 
and so forth. If the entry was for a quadword read, the count bits are set to 
11(BIN) when the reference is sent out. 


UNEXPECTED_FILL 


This bit is set to indicate that an RDE or RDR cycle was received on the NDAL 
with an ID for which the FILL_CAM entry was not valid. When UNEXPECTED_ 
FILL is set, CEFSTS and CEFADR are loaded and locked. 


4.4.9.2 Fill Error Address (CEFADR) 


The CEFADR register holds the address of a fill that ended in an error condition. 
It is loaded when an error is detected on a fill. It is a read-only register. 


CEFADR is locked when CEFSTS is locked. 
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Figure 4-29 IPR Format of CEFADR 


31 03 02 01 00 
Fill Error Address 00/0) 
LJ-01288-TI0 


4.4.10 NDAL Error Registers (NESTS, NEOADR, NEOCMD, NEDATHI, 
NEDATLO, NEICMD) 


The NDAL error registers hold information related to NDAL errors. NESTS, 
NDAL error status, holds error bits relating to any problems encountered. 


NEOADR, NDAL error output address, holds the address corresponding to the 
cycle that was in error. NEOCMD, NDAL error output command, holds the 
command bits corresponding to the cycle in error. 


NEDATHI, NDAL error data high longword, and NEDATLO, NDAL error data 
low longword, hold the data from an NDAL cycle where NVAX detected a parity 
error on the bus. NEICMD, NDAL error input command, holds the command bits 
corresponding to a cycle with a parity error. 


4.4.10.1 NDAL Error Status IPR (NESTS) 


The NESTS register holds information about any errors that happened on the 
NDAL. All six bits in this register are write-one-to-clear. Reset does not affect 
this register. Powerup does not initialize the register. 
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Figure 4-30 IPR Format of NESTS 
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Table 4-28 NESTS IPR Format 
Name Extent Type Description 


NOACK 0 WC Indicates that an outgoing NVAX NDAL 
cycle was not acknowledged by any of 
the other NDAL devices. This bit locks 
NEOADR and NEOCMD. 


BADWDATA 1 WC Indicates that an outgoing NDAL 
data cycle was accompanied by the 
BADWDATA command. This bit locks 


NEOADR and NEOCMD. 

LOST_OERR 2 WC Indicates that multiple outgoing errors, 
either NOACK or BADWDATA, were 
detected. 

PERR 3 WC Indicates that a parity error was 


detected on the NDAL. This bit locks 
NEDATHI, NEDATLO, AND NEICMD. 


INCON_PERR 4 WC Inconsistent parity error. This means 
that although NVAX detected a parity 
error, some other device apparently 
did not and acknowledged the NDAL 
transaction. 


LOST_PERR 5 WC Indicates that multiple NDAL parity 
errors were detected. 


NOACK 

NOACK is set when NVAX detects that the NDAL signal "ACK_L" was not 
asserted by any receiving device on the NDAL for an outgoing NVAX cycle. When 
NOACK is set, NEOADR and NEOCMD are locked so that software can read 
them to see what transaction was being attempted when the error occurred. 


NOACK is set on any outgoing NVAX cycle that is not acknowledged, whether it 
was an address cycle or a data cycle. The information that is locked in NEOADR 
and NEOCMD corresponds to the address cycle of the transaction. For example, 
if an outgoing write data cycle is not acknowledged, the address cycle for that 
write operation is saved in NEOADR and NEOCMD. 
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4-48 


NOACK is not set if there was a previous BADWDATA. If a BADWDATA cycle is 
NOACK’d, both BADWDATA and NOACK are set. 


NOACK is cleared by write-one-to-clear. 


BADWDATA 


BADWDATA is set when the BIU receives data for a write-back from the cache 
that had an uncorrectable ECC error, and thus is being issued on the NDAL with 
the BADWDATA command. When BADWDATA is set, NEOADR and NEOCMD 
are locked so that software can read them to retrieve the information about the 
failure. 


The address for the write operation is captured in NEOADR, and the command 
information for the cycle is captured in NEOCMD. 


NOACK is not set if there was a previous BADWDATA. If a BADWDATA cycle is 
NOACK’d, both BADWDATA and NOACK are set. 
LOST_OERR 


LOST_OERR is set when NOACK or BADWDATA is already set and another one 
of those errors occurred. It notifies software that state was saved only for the 
first outgoing error. 


LOST_OERR is cleared by a write-one-to-clear. 


PERR 


PERR is set when NVAX detects a parity error on the NDAL. When PERR is set, 
NEDATHI, NEDATLO, and NEICMD are locked so that software can read them 
to see what was on the NDAL when the error occurred. 


Since NVAX calculates parity on every cycle, PERR will be set on both its own 
transfers and the transfers of other devices that fail the parity check. 


PERR is cleared by a write-one-to-clear. 


INCON_PERR 


INCON_PERR (inconsistent parity error) is set when an NDAL parity error 

is detected on a cycle, which is also acknowledged with the NDAL signal 
"ACK_L." This means that NVAX detected a parity error but some other device 
acknowledged the transfer. 


INCON_PERR is only set in conjunction with PERR. It is not set unless PERR is 
set. If one NDAL parity error has already occurred, setting PERR, but INCON_ 
PERR was not set for that cycle, a subsequent cycle with an inconsistent parity 
error will not cause INCON_PERR to be set. 


INCON_PERR is cleared by a write-one-to-clear. 


LOST_PERR 


LOST_PERR is set when PERR is already set and another NVAX transfer fails 
the parity check. LOST_PERR notifies software that multiple NVAX transfers 
have failed the parity check; state was saved only for the first. 


LOST_PERR is cleared by a write-one-to-clear. 
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4.4.10.2 NDAL Error Output Address IPR (NEOADR) 


The NEOADR register is loaded for every address cycle that the NVAX drives 
onto the NDAL unless it is locked. It is loaded during the cycle when the 
corresponding ACK_L should be asserted on the NDAL. It is locked when the 
NOACK bit in the NESTS register is set. 


When NEOADR is locked, it contains the address information for the first 
transaction that failed. If it is read when it is not locked, it contains information 
from the last address cycle that was acknowledged on the NDAL. 


The format of NEOADR matches the low longword of the NDAL during an 
address cycle. 


NEOADR is read-only to software. 


Figure 4-31 IPR Format of NEOADR 


31 00 
NDAL Address 
LJ-01290-TIO 


4.4.10.3 NDAL Error Output Command (NEOCMD) 
The NEOCMD register is loaded and locked exactly as NEOADR is loaded and 
locked. The format of NEOCMD is similar to that of the high longword of the 
NDAL during an address cycle. The high quadword byte enable positions are 
NOT included, since NVAX only uses quadword byte-enabled transactions. The 
NDAL ID and command are added in the lower seven bits of the longword. 


Figure 4-32 IPR Format of NEOCMD 


31 30 2928 27 26 25 24 23 22 21 20 1918 17 16 15 08 07 06 04 03 
Pe] eee [le | a 
LJ-01291-T10 
Table 4-29 NEOCMD IPR Format 
Name Extent Type Description 
CMD 3:0 RO NDAL command as driven by NVAX 
during the transaction. 
ID 6:4 RO Commander ID as driven by NVAX 
during the transaction. 
BYTE_EN 15:8 RO Byte enable as driven by NVAX during 
the transaction. 
LEN 31:30 RO Length of the NDAL transaction. 
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4.4.10.4 NDAL Error Input Command (NEICMD) 


NEICMD, NEDATHI, and NEDATLO are loaded at the same time and they are 
locked at the same time. They are all loaded when a parity error occurs; at this 
time the PERR bit is set in NESTS, which locks the three registers. If a second 
NDAL parity error happens, the registers are not loaded again. They are not 
loaded again until after they are unlocked when software clears PERR. 


NEICMD contains the NDAL signals CMD_H<3:0>, ID_H<2:0>, and PARITY_ 
H<2:0> from the failed transfer. 


NEICMD is a read-only register. 


Figure 4-33 IPR Format of NEICMD 
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PARITY 
The PARITY field corresponds to the NDAL lines PARITY_H<2:0>. 


ID 
The ID field corresponds to the NDAL lines ID_H<2:0>. 


CMD 
The CMD field corresponds to the NDAL lines CMD_H<3:0>. 


4.4.10.5 NDAL Error Data High and NDAL Error Data Low (NEDATHI and NEDATLO) 


NEDATHI and NEDATLO behave similarly to NEICMD. They capture NDAL_ 
H<63:0> during a cycle with a parity error. NEDATHI contains the high longword 
of data from the NDAL (NDAL_H<63:32>); NEDATLO contains the low longword 
of data from the NDAL (NDAL_H<31:0>). 


The format of NEDATHI and NEDATLO must be interpreted based on the CMD 
found in NEICMD. If the CMD field shows that the cycle was a data cycle, the 
registers contain two longwords of data. If the CMD field shows that the cycle 
was an address cycle, the registers are in the format of an NDAL address cycle, 
as shown in Figure 4—34 and Figure 4-35. 


Figure 4-34 NEDATHI, Address Cycle Format 


31 30 29 24 23 08 07 00 


LEN Undefined BYTE_EN Undefined 


LJ-01293-TI0 
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Figure 4-35 NEDATLO, Address Cycle Format 


31 00 
LJ-01294-TlO 


4.4.11 Backup Cache Tag Store Access Through IPR Reads and Writes 
(BCTAG) 


Direct access to the backup cache tag store is provided to aid in error recovery 
and diagnosis and to assist testing. These accesses work whether the cache is on 
or off, in ETM or in force hit mode. 


If there is a valid FILL_CAM entry for the same cache block that is being 
accessed through an IPR read or write, the IPR read or write is stalled until the 
fills return and the FILL_CAM entry is no longer valid. 


When the backup cache tag store is being accessed through IPR reads and writes, 
address bits <24:22> = 100 (BINARY). Address bits <18:5> (KA680) or <18:5> 
(KA680) are used as the index into the tag store RAMs; these indicate which 
backup cache location is to be written or read. 


Figure 4-36 Backup Cache Tag Store IPR Addressing Format 


31 25 24 23 22 21 20 1918 17 16 05 04 00 


LJ-01295-T10 


The format for reading and writing the backup cache tag store as an IPR is 
described in Figure 4-37 and Table 4-30. 


Figure 4-37 IPR Format of the Backup Cache Tag Store 


31 30 29 28 17 16 11 10 09 08 07 06 05 04 03 02 01 00 
pep tee ee | x x xf xxx xx 
VALID 
OWNED 


LJ-01296-T10 
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Table 4-30 Bcache Tag IPR Format 


Name Extent Type Description 
VALID 9 RW Valid Bit 
OWNED 10 RW Ownership Bit 
ECC 16:11 RW! ECC Check Bits 
TAG 28:17 RW Tag Data 


IThe ECC bits are written from the value given in the MTPR instruction only if the SW_ECC bit of 
the CCTL IPR is set. Otherwise, the Cbox generates and writes correct ECC for the tag, owned and 
valid values. 


Table 4-31 Tag and Index Interpretation for BCTAG IPR 
Cache Size Tag Bits Used Index Bits Used 
128 KB (KA680) TAG<28:17> Index<16:5> 


The tag store must be initialized to a known state when the chip is powered up. 
This is done through the MTPR instruction to BCTAG. 


When the tag store is read, the ECC check bits are read out directly from the tag 
store in the format shown. ECC is not checked on IPR accesses to the tag store; 
no errors can occur during these accesses. 


Some care must be taken if IPR reads of the tag store are done while other 
transactions are in progress. The tag information read out may not be what 

the programmer expects if cache misses or cache coherency transactions are in 
progress on the block being read. For example, if a cache miss is in progress, the 
new tag will be in the tag store but the valid and owned bits will be clear. 


4.4.12 Backup Cache Deallocates Through IPR Access (BCFLUSH) 


The backup cache deallocate IPR is a write-only register that software uses to 
explicitly request the deallocation of a cache block. For example, this register 
may be used when hardware has put the cache into ETM and software wants to 
request write-back of the owned blocks to memory. 


If there is a FILL_CAM entry for the same cache block that is being flushed, the 
flush is stalled until the fills return and the FILL_CAM entry is no longer valid. 


Figure 4-38 Backup Cache Deallocate IPR Addressing Format 


31 25 24 23 22 21 20 1918 17 16 05 04 00 


LJ-01297-T10 


When BCFLUSH is written, the NVAX accesses the Bcache tag store. If the block 
is invalid, no further action is taken. If the block is valid but not owned, the 
NVAX invalidates the entry in the Bcache tag store, as well as the corresponding 
Pcache entry if it exists. If the block is valid and owned, the NVAX invalidates 
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the Pcache entry if it exists, performs a write-back of the Bcache data, and 
invalidates the Bcache entry in the tag store. 


This behavior takes place whether the cache is on, off, in ETM, or in FORCE_HIT 
mode. In FORCE_HIT mode, BCFLUSH does a real lookup of the tag store and 
does not force the access to hit. Software must take care not to force deallocates 
when cache state is not consistent with the state of memory. For example, when 
the cache is off, valid and owned bits may be set for blocks that are no longer 
up-to-date with respect to memory. 


When a deallocate is done, the VALID and OWNED bits will be cleared 
as necessary, and the value of the stored TAG is modified. Its value is 
UNPREDICTABLE. Correct ECC is stored on the tag store entry. 


A BCFLUSH operation never changes the data stored in the data RAMs. 
Errors are detected and reported during BCFLUSH operations. 
The index given is interpreted as in Table 4—31, based on the size of the cache. 


BCFLUSH may be used when the Beache is on, because the Pcache is kept 
a subset of the Bceache during these operations. However, new blocks may be 
allocated due to memory reads and writes as the cache is being flushed. 


4.4.13  Bcache Abnormal Conditions 


This section describes the various modes of Bcache behavior as well as Cbox 
response when it detects an error. 


The Bcache has four operating states that are controlled by the following bits in 
the CCTL register: ENABLE, FORCE_HIT, SW_ETM, and HW_ETM. The four 
states are ON, OFF, ETM, and FORCE_HIT. The four states are determined and 
prioritized as follows: 


1. OFF. If the ENABLE bit is cleared in CCTL, the Beache is OFF and those 
conditions take precedence. 


2. FORCE_HIT. If the ENABLE bit is set and FORCE_HIT is set, the Bcache is 
in FORCE_HIT mode and those conditions take precedence. 


3. ETM. If the ENABLE bit is set, FORCE_HIT is cleared, and either SW_ETM 
or HW_ETM is set. The cache is in ETM mode and those conditions take 
precedence. 


4. ON. If the ENABLE bit is set and FORCE_HIT, SW_ETM, and HW_ETM are 
cleared, the cache is ON. 


The ON state is the normal operating condition of the cache. OFF, FORCE_HIT, 
and ETM modes are described in the following sections. 


4.4.13.1| NVAX Behavior When the Backup Cache is OFF 


The backup cache may be off for two reasons: the chip has just powered up, or 
software has disabled the cache by clearing the ENABLE bit in the Bcache control 
register. 


When the cache is off, no accesses to the backup cache are done. Errors are not 
detected and cache state is UNCHANGED unless explicitly changed by software 
through IPR reads and writes. 
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When the backup cache is off, all cache lookups due to DMA cycles on the NDAL 
are forwarded as invalidates to the Pcache, since the data may be valid in the 
Pcache. All reads that miss in the Pcache go directly to the NDAL. Cache fills 
returning from the memory subsystem are sent directly to the Peache without 
incurring the overhead of Bcache access. All writes go directly to the NDAL. 


When the cache is off, VAX interlocked instructions that generate atomic 
read/write pairs become hexaword ownership read/quadword disown write on 
the NDAL. 


All writes issued from NVAX when it is operating without a backup cache are of 
quadword length. Memory reads are of hexaword length since the Peache block 
size is a hexaword. Even if the Pcache is off, a hexaword of data is returned to 

the Mbox. 


A VAX instruction that generates read references with modify intent normally 
generates an OREAD on the NDAL if it misses in the Bcache. However, when the 
Beache is off, a normal DREAD is used on the NDAL. 
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4.4.13.2 NVAX Behavior When the Backup Cache is in FORCE_HIT Mode 


FORCE_HIT mode is intended to be used for testing purposes only. It is used 
when the cache is enabled. 


When FORCE_HIT is set, all memory space reads and writes to the Bcache, both 
I-stream and D-stream, are forced to hit. Tag store state is not changed at all; 
the data RAMs are accessed as if the tag store access produced an owned-valid 
hit. DMA I/O references on the NDAL are treated as they are when the Bceache 
is off. They are not looked up in the backup cache; they are all forwarded to the 
Peache as invalidates, and Bcache state is not changed as the result of the DMA 
references. 


When the Bcache is in FORCE_HIT mode, deallocates are not done. Even if the 
tag matches and the VALID and OWNED bits are set, the block is not written 
back. The implication of this is that if FORCE_HIT mode is being used, the 
Beache must be flushed of all owned blocks beforehand. 


Tag store and data RAM ECC errors are detected in FORCE_HIT mode if 
DISABLE_ERRORS in the CCTL register is not set, resulting in the usual 
error handling. 


As an example of the use of FORCE_HIT mode, suppose the ECC logic for the 
data RAMs is to be tested. Put the cache in FORCE_HIT mode. Set SW_ECC in 
the Bceache control register. Write the desired ECC into BCDECC. Do a write to 
a memory location that maps to the desired Bcache block, and the location will 
be written using ECC from BCDECC rather than from NVAX-generated ECC. 
Suppose the ECC written is such that when the data is read, an ECC error will 
be flagged. 


Now perform a read of the same memory while FORCE_HIT is still set. The 
read will result in a Bcache data ECC error, showing that the logic is working 
correctly. The data RAM error registers may be read and will correspond to the 
induced error. 


4.4.13.3  NVAX Behavior When the Backup Cache is in Error Transition Mode 


When the NVAX detects certain errors, it puts itself into error transition mode 
(ETM). 


The goals of the Bcache design during ETM are the following: 
1. Preserve the state of the Bcache as much as possible for diagnostic software. 


2. Honor references that hit owned blocks in the backup cache since this is the 
only source of data in the system. 


3. Respond to NDAL DMA references normally (that is, write-back owned 
blocks that are referenced by DMA devices), and perform invalidates on 
DMA-referenced cached unowned blocks. 


Once the NVAX enters error transition mode, it remains in ETM until software 
explicitly disables or enables the Bcache. To ensure Bcache coherency with 
main memory, the Bcache must be completely flushed of valid blocks before it is 
re-enabled because some data can become stale while the cache is in ETM. 


Table 4-32 describes how the backup cache behaves while it is in ETM. 
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Table 4-32 Backup Cache Behavior During ETM 


—___—_———_Cache 

Cache Response————- 

Transaction Miss Valid Hit Owned Hit 

CPU IREAD,DREAD Read from memory Read from memory Read from 
cache 

CPU READ_LOCK Read from memory Read from memory Force block 
write-back, 
read from 
memory? 

CPU Write Write to memory Write to memory Force block 
write-back, 
write to 
memory! 

CPU WRITE_ Write to memory Write to memory Write to 

UNLOCK cache! 

Fill (from read started —-Normal cache behavior— 

before ETM) 

Fill (from read started —-Do not update backup cache; return data to Mbox—- 

during ETM) 

NDAL DMA reference —-Normal cache behavior—- 


Done to preserve write ordering 


Any reads or writes that do not hit valid-owned during ETM are sent to memory; 
read data is retrieved from memory, and writes are written to memory, bypassing 
the Beache entirely. 


The cache supplies data for IREADs, DREADs, and dread modifies that hit 
valid-owned; this is normal cache behavior. 


If a write hits a valid-owned block in the cache, the block is written back to 
memory and the write is also sent to memory. 


If a READ_LOCK hits valid-owned in the cache, a write-back of the block is 
forced and the READ_LOCK is sent to memory (as an OREAD on the NDAL). 


Data returning from the memory subsystem as the result of any type of read 
originated before the Bcache entered ETM are processed in the usual fashion. If 
the returning cache fill is a result of a write miss, the write data is merged, as 
usual, as the requested fill returns. Fills caused by any type of read originated 
during ETM are not written into the Bcache or validated in the tag store. 


During ETM, the state of the cache is modified as little as possible. Table 4—33 
shows how each transaction modifies the state of the cache. 
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Table 4-33 Backup Cache State Changes During ETM 
-Cache State 


Cache Modified 

Transaction Miss Valid Hit Owned Hit 

CPU IREAD,DREAD None None None. 

CPU READ_LOCK None None Clear 
VALID and 
OWNED; 
change 
TS_ECC 
accordingly. 

CPU Write None None Clear 
VALID and 
OWNED; 
change 
TS_ECC 
accordingly. 

CPU WRITE_ None None Write new 

UNLOCK data; change 
DR_ECC 
accordingly. 

Fill (from read started Write new TS_TAG, TS_VALID, 

before ETM) TS_OWNED, TS_ECC, DR_DATA, DR_ECC 

Fill (from read started None - 

during ETM) 

NDAL DMA ——-Clear VALID and OWNED; 

transaction change TS_ECC accordingly 


4.4.14 How to Turn the Bcache Off 


Because the Beache is a write-back cache, care must be taken to maintain cache 
coherency when turning it off. 


If the cache is running normally and software wishes to turn it off, it must do the 
following: 


1. Write to CCTL register to set SW_ETM. In this mode, the Beache will not 
allocate any new blocks and will send all DMA-caused Bcache lookups to the 
Pcache as invalidates. 


2. Use the BCFLUSH register to flush all owned blocks out of the cache. 


3. Turn off the Bcache by writing the CCTL register to clear ENABLE and 
SW_ETM simultaneously. If an error was encountered during the deallocate 
process, HW_ETM may be set. If so, it should be cleared as well. 


If the Beache encounters an uncorrectable ECC error, the NVAX sets HW_ETM 
in the CCTL register. If software wishes to turn off the cache, it must do the 
following: 


1. Use the BCFLUSH register to flush all owned blocks out of the cache. 


2. Write CCTL to clear ENABLE and clear HW_ETM simultaneously. This 
turns off the Beache. 
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4.4.15 How 


If Beache errors are occurring only in part of the cache, software may be able to 
avoid the portion of the cache that is in error by disabling it through the use of 
the SIZE field in CCTL. If part of the cache is failing, a smaller cache size may 
be selected so that only part of the cache RAMs is being used. The cache must be 
flushed before changing the cache size so that the tags are correct. 


This works only if the smallest cache size is not being used, and if the failing 
areas of cache do not fall within the range of the smaller cache size selected. 


to Turn the Bcache On 


When NVAX powers up, garbage data is stored in the Beache tags and data. This 
would result in ECC errors if the cache were turned on immediately. 


Through IPR writes, every Bcache tag store entry must be written with cleared 
OWNED and VALID bits. The value written to the tag is irrelevant, as long as 
correct ECC is written to the tag store. 


Once the tag store has been initialized, the cache may be enabled by setting 
ENABLE in the CCTL register. 


It is not strictly necessary to initialize the Bcache data RAMs with correct ECC 
on powerup. ECC errors in the data RAMs are ignored if the corresponding tag 
store entry is invalid. Since data RAM ECC errors are not detected on fills, the 
cache data is self-initializing. 


FORCE_HIT mode may be used to initialize the Bcache data RAMs with correct 
ECC. If full quadword writes are used, no data RAM errors will be detected 
during this process, since the RAMs are written without being read first. If 
partial quadword writes are used, errors will be detected because of the read- 
modify-write that is necessary. If the programmer sets the DISABLE_ERRORS 
bit in the CCTL register, the NVAX will ignore these errors. 


If the Bcache is in ETM, it may be incoherent with respect to memory because 
of how it treats writes that hit valid but not owned in the cache (Table 4—32). In 
addition, the Pcache, if enabled, is no longer a subset of the backup cache. The 
procedure for turning on the Peache and the Bcache as described in this section 
must be followed. 


If the Bceache is operating normally and is turned off for some reason, the 
programmer must ensure that when it is re-enabled, all the OWNED and VALID 
bits are cleared. 


4.4.16 Backup Cache Errors 


In general, the NVAX logs as much state as possible concerning errors and 
notifies the Ebox and/or Mbox that an error has occurred. For every error, the 
NVAX does at least one of the following to notify software of the error: hard error 
interrupt, soft error interrupt, or machine check exception. The backup cache 
goes into error transition mode when it detects any uncorrectable error from the 
cache RAMs. 
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Table 4-34 Backup Cache ECC Errors and NVAX CPU Error Responses 


General Problem 


Specific Situation and Action Taken by NVAX CPU 


Correctable ECC 
error in the data 
RAMs 


Uncorrectable ECC 
error in the data 
RAMs (includes 
addressing errors) 


Correctable ECC 
error in the tag 
store 


Read hit for write- 
back or read hit for 
deallocate IPR 


Read hit for Pcache 
miss 
Read for write hit 


Miss 


Read for write-back 
or deallocate IPR 


VALID-OWNED or 
VALID-UNOWNED 
read for Pcache miss 


VALID-OWNED 
DREAD_LOCK, first 
quadword fails 


VALID-OWNED 
DREAD_LOCK 

for Peache miss, 
quadword other than 
the first one fails 


Read for write, valid- 
owned hit, or write 
unlock 


Miss 


Any read or write 
except WUNLOCK; 
hit or miss 


Soft error interrupt. The data for the 
write-back is corrected and the write-back 
continues normally. 


Soft error interrupt. 


Soft error interrupt. The corrected data is 
merged with the write data and written 
into the RAMs. 


No error is reported. 


Soft error interrupt, puts backup cache 
into ETM. The data cycle command for the 
NDAL is changed to BADWDATA and the 
write-back continues normally. 


Soft error interrupt, puts backup cache into 
ETM. 


Soft error interrupt, puts backup cache into 
ETM. 


Soft error interrupt, puts backup cache into 
ETM. 


Hard error interrupt, puts backup cache 
into ETM. When the error is detected, write 
data has already been merged with the 
corrupted data. 


The NVAX inverts three of the ECC 
check bits (bits 3,6,7), which gives a 
high probability that when the data is 
read again, an uncorrectable error will be 
detected. 


No error is reported. 


NVAX takes a soft error interrupt, assumes 
the transaction missed, and sends a READ 
or an OREAD to memory. If the location 
was owned, making a deallocate necessary, 
the outgoing address is corrected for the 
write-back. 


Note that if the transaction actually hit- 
owned, the READ or OREAD is sent to the 
NDAL followed by a write-back of the same 
block. The errored location is corrected by 
hardware when the tag and valid bit are 
written for the fill. 


(continued on next page) 
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Table 4-34 (Cont.) Backup Cache ECC Errors and NVAX CPU Error Responses 
General Problem Specific Situation and Action Taken by NVAX CPU 


DMA cache Soft error interrupt. Hardware does not 
coherence correct the bad location; it may be done by 
transaction miss software. 
DMA cache Soft error interrupt. Writes the corrected 
coherence tag, valid, and owned bits back into the tag 
transaction hit store when invalidating the entry. Uses 
corrected address for the write-back if 
necessary. 
Uncorrectable ECC Read for Peache miss Soft error interrupt. Backup cache put into 
error in the tag ETM. The read is sent to memory; if the 
store (includes backup cache actually owned the block, the 
addressing errors) read will time out. 
Write Soft error interrupt. Backup cache put into 


ETM. The OREAD for the write is sent to 
memory. If the cache actually owned the 
block, the read will time out and the write 
will then be sent to memory. The write will 
then time out as well unless error handling 
software cleans up the problem. 


If the cache did not own the block, the 
OREAD will complete, the write will be 
merged with it, and the merged data will 
be written to the cache. 


WRITE_UNLOCK No tag store lookup is done, so this case 
does not occur. 


DMA cache Soft error interrupt. Backup cache put 
coherence into ETM. Transaction is treated as a 
transaction miss with regard to the backup cache; the 


invalidate is forwarded to the Pcache if the 
cache coherence transaction were due to an 
OREAD or a WRITE. 
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4.4.16.1 Backup Cache Errors Incurred While in Error Transition Mode 


Table 4-35 describes error handling when the backup cache is already in ETM. 


Note 


The table below only describes ETM error cases that differ from error 
handling when the cache is in normal mode. 


Table 4-35 Backup Cache ECC Error Handling During ETM 


General Problem 


Specific Situation and Action Taken by NVAX CPU 


Uncorrectable ECC 
error in the data 
RAMs (includes 
addressing errors) 


Uncorrectable ECC 
error in the tag 
store (includes 
addressing errors) 


Read for WRITE_ 
UNLOCK, VALID- 
OWNED hit 


Write 


WRITE_UNLOCK 


Hard error interrupt. When the error 
is detected, write data has already been 
merged with the corrupted data. 


The NVAX inverts three of the ECC 
check bits (bits 3,6,7), which gives a 
high probability that when the data is 
read again, an uncorrectable error will be 
detected. 


Soft error interrupt. The write is sent 

to memory. If the cache actually owned 
the block, the write will time out in the 
memory interface unless software forces the 
Cbox to disown the block. 


If the cache did not own the block, the 
system handles the write as it normally 
does for a cache that is off. 


Soft error interrupt. The write is sent to 
memory as a quadword length WDISOWN. 
Since the READ_LOCK was done just 
previously, memory always believes that 
the Bcache owns the block. 


In most cases, the cache itself does not have 
a record of owning the block since a READ 
LOCK to an owned block during ETM 
forces a write-back of the block. In these 
cases, the WRITE_UNLOCK handling is 
very consistent. 


There is only one case where the cache 
does own the block: if we entered ETM on 
or after the READ_LOCK and before the 
WRITE_UNLOCK. In this case, the cache 
may contain previously written data that is 
not now reflected into memory. This may 
be handled by software. 
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The main memory system is implemented in the NVAX memory controller chip 
(NMC). The NMC communicates with the MS690 memory boards over the MS690 
memory interconnect. Up to four MS690 memory boards are supported, for a 
maximum of 512 MB of main memory. 


The NMC serves as an interface between the NDAL and the NVAX memory 
interconnect. The NMI is comprised of the set of signals leading from the NMC 
to the memory modules, and provides a 64-bit path to the memory modules. The 
arbiter for the NDAL is also built into the NMC. 


5.1 Overview of the NVAX Memory Subsystem Support Functions 
There are two chips that support the memory subsystem: 
¢ The NVAX memory controller chip (NMC). 
¢ The GMI memory interface chip (GMX). 


5.1.1 The NMC Chip 


The NMC controls and passes data to or from one, two, three, or four buffered 
memory modules using a bank interleaved memory access. It responds to 
commands from the CPU and the I/O adaptor (NCA). The NMC is never a 
commander on the NDAL. 


The memory interconnect to the NMC supports the MS690 64-bit memory 
modules. 


The MS690 memory module can have one or two banks of 1 Mb or 4 Mb DRAMs. 
Each bank consists of 72-1 Mb or 72-4 Mb Fast page mode 100 ns RAS access 
time DRAMs. Of the 72 RAMs, 64 are used to store data. The remaining 8 RAMs 
are used for storing ECC bits. 


A given memory module is always populated with only one size of DRAM chips. 
The size of the memory bank is determined by reading the configuration from the 
memory modules. A single memory module has two banks of memory in which 
each bank is 16 MB or 64 MB for 1 Mb and 4 Mb DRAMs, respectively. 


There is one ownership bit (O-bit) for each hexaword of data in memory. These 
ownership bits are implemented on the CPU module and are distinct from the 
MS690 memory boards. The CPU uses ownership reads (OREADs) to obtain 
ownership of a hexaword of data that it wishes to modify. Interlocked reads 
are also done as OREADs. I/O devices use OREADs to perform interlock read 
transactions. The ownership bits are set as a result of OREADs issued on the 
NDAL and are cleared by a disown write. The control signals for the O-bits are 
provided by a separate port on the NMC. 
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The CPU uses I-stream or D-stream reads to read locations that it will not 
modify, and ownership reads to access locations it wishes to modify (when the 
backup cache is on). The I/O devices use D-stream reads to do reads without 
locks, and ownership read/disown write pairs to implement locked transactions. 


5.1.2 The GMX Chip 
The GMX is a 20-bit data multiplexer and transceiver that buffers DRAMs on 
a memory module. It also includes support for a high-speed memory diagnostic 
function. It is the interface between the CMOS NMI and the TTL DRAM array. 
5.2 Overview of NMC-supported NDAL Transactions 


The NDAL is a 64-bit pended, synchronous bus with multiplexed data and 
address lines and centralized arbitration. All the components that interface to it 
use four clock signals from the NVAX CPU chip. The NMC is the arbiter and the 
default bus master. The following transactions are supported on the NDAL: 


e IREAD, I-stream read. 

¢ DREAD, D-stream read (no lock or ownership). 
¢ OREAD, D-stream read ownership. 

e RDE, read data error. 

¢ WRITE, write masked (no disown or unlock). 


¢ WDISOWN, disown write. These transactions use WDATA cycles to transmit 
write data. If the data is in error, a BADWDATA cycle is used instead. 


e RDRO,RDR1,RDR2,RDR3, read data return (0 to 3). 
¢ NOP. 


5.3 Overview of NMI Transactions 
The NMC performs the following transactions on the NMI: 
¢ Quadword, octaword, and hexword OREADs, IREADs, and DREADs 


¢ Longword, quadword, octaword, and hexword WRITEs (masked, no disown or 
unlock) 


¢ Quadword and hexword disown writes 
e Signature read 
¢ Memory refresh 


e Fast diagnostic test mode read or write 


5.4 NMC Architectural Overview 


The NVAX memory controller (NMC) serves as an interface between the NDAL 
(NVAX data-address lines) and the memory subsystem over a private interconnect 
(NMI), which is 64 bits. The NMC also serves as the arbiter for the nodes on the 
NDAL. The NMC is made up of five major sections - the NDAL interface, the 
memory interface, the control and status registers, the transactions handler, and 
the NDAL arbiter. This section describes these five sections and their interaction. 
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5.4.1 NDAL Bus Interface Architecture 


The system has three nodes on the NDAL - the NMC, the NVAX CPU, and 

the NCA (CP-bus adapter). The NVAX CPU and the NMC can do memory 
transactions on the NDAL, but only the CPU can do I/O transactions. The NMC 
services all memory transactions (address<31:29>= 000..110) and I/O transactions 
written within its I/O space (address 2101 0000 - 2101 804C, 2100 0110). The 
NMC supports the following transactions on the NDAL: 


¢ OREAD - ownership read 
e IREAD - I-stream read 

¢ DREAD - D-stream read 

¢ WDISOWN - disown write 
¢ WRITE - masked write 


Every transaction on the NDAL is decoded and loaded into an appropriate input 
queue in the NMC. The NMC has four input queues; CPU_QUE, IO1_QUE, IO2_ 
QUE, and WB_QUE. The CPU_QUE, I01_QUE, and I02_QUE queues (these 
will be collectively referred to as non-writeback queues, or NWB_QUEs) buffer up 
non-writeback transactions - OREADs, IREADs, DREADs, WRITEs. All disown 
writes (WDISOWN) are buffered in the writeback queue - WB_QUE. All four 
queues have one entry each. 


5.4.1.1. The Non-Writeback Queues 


Every NWB_QUE entry contains an address packet, a data packet, a valid bit, 
a pending bit, and two mark bits. Figure 5-1 illustrates the organization of the 
NDAL IN_QUEs in the NMC. 


The address packet consists of the following: 
e Address - 32 bits 

¢ Command - 4 bits 

¢ Commander ID - 3 bits 

¢ Byte mask - 16 bits 

¢ Transfer length - 2 bits 


The data packet in the IO1_QUE and IO2_QUE consists of 4 quadwords of data 
and the corresponding parity information. The data packet in the CPU_QUE 
consists of one quadword and the corresponding parity. The CPU_QUE data 
packet is only one quadword wide because during normal operation, the only 
writes coming from the NVAX CPU and going to memory will be write-backs, 
which will go into the write-back queue. The CPU_QUE will only be used when 
the Beache is off or in error transition mode. In this case, the NVAX CPU writes 
are all of quadword length. 
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Figure 5-1 NDAL IN_QUEs in the NMC 
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The valid bit is set whenever a transaction is loaded into the queue. This 

also asserts a request to an internal arbiter, SEL_TRANS, which selects the 
transactions to be serviced by the NMC according to their priority. The valid bit 
is set until the transaction can be completed in memory. Refer to Section 5.4.9.1 
for details. 


When a memory transaction is serviced, and the corresponding hexaword 

is owned by another NDAL node, a pending bit is set in the NWB_QUE 
corresponding to that memory transaction. This bit is set until the corresponding 
disown write is received. Every NWB_QUE is also associated with a pending 
timer that counts the number of cycles a transaction has been waiting for a 
disown write. 


Each NWB_QUE entry has two mark bits corresponding to the other two NWB_ 
QUEs. For instance, the CPU_QUE has two mark bits - I01_MARK and IO2_ 
MARK; the IO1_QUE has mark bits CPU_LMARK and IO2_MARK; and the IO2_ 
QUE has mark bits CPU_MARK and IO1_MARK. These mark bits are used to 
preserve ordering of the NDAL transactions. Ordering of transactions on the 
NDAL has to be preserved because not all devices use interlocked transactions for 
synchronization; some devices use memory reads, IO reads/writes, or interrupts. 
The NMC does not monitor all these synchronization events on the NDAL and 
therefore has to maintain order of transactions to the same hexaword address. 
This is done in the following way. 
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When the NMC sees a non-writeback memory transaction on the NDAL from a 
node, it performs a hexaword address compare between the incoming address 
and the addresses stored in valid entries of the NWB_QUEs corresponding to 
the other two commander nodes on the NDAL. If there is a match, the mark 
bit corresponding to the commander ID of the incoming transaction is set in the 
NWB_QUE that matched. The incoming transaction will not be serviced by the 
NMC until all transactions marked for its ID have been serviced. For example, 
the CPU does a read to hexaword H1. H1 is compared with the addresses in 
IO01_QUE and IO02_QUE. Suppose address H1 corresponds to a valid address in 
IO01_QUE. The CPU_MARK bit is set in IO01_QUE. The CPU read from H1 is not 
serviced by the NMC until the transaction from I01_QUE is done. In this way, 
the ordering of NDAL transactions is maintained by the NMC. 


5.4.1.2 The Write-back Queue 


WB_QUE contains an address packet, a hexaword data packet, and a valid bit 
similar to the NWB_QUEs. 


When a memory space disown write (WDISOWN) happens on the NDAL, the 
NMC compares the hexaword address of the disown write to valid addresses 
in the NWB_QUEs. If there is a match, and the corresponding transaction is 
pending, the transaction is selected for completion along with the disown write. 
This is described in greater detail in Section 5.4.9. The NMC allows disown 
writes to bypass non-writeback transactions. 


WB_QUE is given the highest priority by the NMC, except when Q22-bus devices 
are accessing main memory. In this case, the CP-bus connected to the CQBIC is 
given highest priority. This is done to reduce the latency on Q22-bus transactions 
to main memory. 


5.4.1.3 The OUT_QUE 


When a read is serviced by the NMC, data to be returned on the NDAL is loaded 
into an "outgoing" data queue, the OUT_QUE. The OUT_QUE is unloaded when 
the NDAL is granted to the NMC. It can store up to 6 entries; each entry consists 
of 64 bits of data, the commander ID, error information, and the quadword 
number. Parity is generated as the information is sent from the OUT_QUE into 
the output pad latch. Data from the OUT_QUE is returned in the order in which 
it was loaded; the requested data is always returned first. Data is not necessarily 
returned in consecutive cycles. 


5.4.2 Memory Interface Architecture 


The NMC supports up to 128 MB of memory using 1 Mb DRAMs only and up to 
512 MB of memory using 4 Mb DRAMs only. The minimum memory increment 
is 16 MB with 1 Mb DRAMs and 64 MB with 4 Mb DRAMs. The maximum 
available physical memory is divided into 8 sets. Each set is 16 MB if memory is 
made up of 1 Mb DRAMs and 64 MB if memory is made up of 4 Mb DRAMs. The 
NMC supports the use of 1 Mb DRAM-based memory modules with 4 Mb-based 
memory modules in the same system. 


The NMC supports a single error correcting/double error detecting/single symbol 
detecting (SEC/DED/SSD) code on memory data. On the 64-bit MS690 memory 
modules, 72 bits are implemented - 64 bits for data and 8 ECC check bits. 


Every hexaword in memory has a corresponding ownership bit (O-bit) associated 
with it. Single error correction on the O-bits is done by generating 4 ECC check 
bits across 8 O-bits. Since the system can support up to 512 MB of main memory, 
corresponding to 16M hexawords, there are 16M O-bits implemented on the CPU 
module. The NMC provides a separate O-bit port to access the O-bit memory. 
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The NMI supports 2-way memory interleaving. Pagemode operation of the 
DRAMs is used within a transaction but not across transactions. The NMC 
provides the basic control and timing for data memory and ownership bit memory. 
For details about the organization of the memory modules and the NMI interface, 
refer to Section 5.6. 


5.4.2.1. Data Memory Addressing 


The NVAX memory space ranges from address<31:29> = 000 to address<31:29> 
= 110. The NVAX CPU is configured in 30-bit address mode; therefore, the 
maximum memory space it can support is 512 MB (bits <31:30> are ignored). 
Each set of memory can be mapped anywhere in this 512 MB of NVAX memory 
space (see the following paragraph). If a set is made up of 1 Mb DRAMs (16 
MB set), 24 bits of the address are required to reference a byte within the set. 
Address bits <23:0> are used for this purpose. Address bits <28:24> are used to 
select the appropriate set. These bits contain the base address of this set. Ifa 
set is made up of 4 Mb DRAMs (64 MB set), 26 bits of the address are required 
to reference a byte within the set. Address bits <25:0> are used for this purpose. 
Address bits <28:26> are used to select the appropriate set. These bits contain 
the base address of this set. 


A set can therefore be configured to map to any value of bits 28:24 if it is made 
up of 1 Mb DRAMs (bits 28:26 if it is made up of 4 Mb DRAMs). This base 
address mapping is stored in a corresponding configuration register. When a 
validated base address value matches the incoming address, the corresponding 
set is selected for reading or writing. Refer to Section 5.4.2.3 and Table 5-1 for 
further details. 


5.4.2.2 Memory Set Organization 
A memory set can be 16 MB or 64 MB. Each set on an MS690 memory module is 
made up of two banks of 72 DRAMs each. These banks are quadword interleaved; 
bit <3> of the address is used to select between even and odd banks. When bit 
<3> is 0, the even bank is selected; when bit <3> is 1, the odd bank is selected. 
Figure 5-2 illustrates this. 


Figure 5-2 Data Memory Addressing 
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The following table shows the NDAL to memory address mapping for 1 Mb and 4 
Mb DRAMs. 


Table 5-1 Memory Address Mapping for Data 


DRAM Size Base Address Row Address<10:0> Column Address<10:0> 
1M <31:24> <23:14> <13:4> 
4M <31:26> <25, 23:14> <24, 13:4> 


5.4.2.3. Memory Configuration 
The NMC supports eight memory sets. Corresponding to each set is 
a configuration register and a signature register (Section 5.4.8.1.1 and 
Section 5.4.8.1.2). MEMCONO and MEMSIGO correspond to memory set 0, 
MEMCON1 and MEMSIGI1 correspond to memory set 1, and so on. By loading 
the appropriate address in the corresponding configuration register, a set can be 
mapped to any 16 MB (for 1 Mb DRAMs) or 64 MB (for 4 Mb DRAMs) segment 
of the NVAX memory space. For instance, a base address of 0 in MEMCON7 
would map bank set 7 to the lowest 16 MB (for 1 Mb DRAMs) or 64 MB (for 4 Mb 
DRAMs) of NVAX memory space. 


Memory banks can be made up of 1 Mb DRAMs or 4 Mb DRAMs. The size of 
each memory bank can be obtained by using the following 2-step procedure: 


1. Software reads the corresponding memory signature register (one of 
MEMSIGO - MEMSIG7). This would cause the NMC to read the signature of 
the appropriate memory set and return it on the NDAL. 


2. Software should then determine from this signature the type of memory set 
on the selected module, and then program the memory configuration register 
appropriately. Also stored in each memory configuration register is the base 
address to which each memory set responds, and a valid bit to indicate that 
the contents of the associated memory configuration register (MEMCONO - 
MEMCON7) is valid. 


A signature of 11 (binary) indicates that the corresponding set is not present in 
the system. The total number of sets in the system can be determined by keeping 
count of the number of signatures with no sets. Having determined the number of 
sets and their sizes, software can program the base addresses in the base address 
registers. 


The signatures that will be returned for each of the four possible memory 
configurations a memory set may have are listed in Table 5-2. 


Table 5-2 Memory Signature Configurations 


Signature with 1 Mb DRAMs Signature with 4 Mb DRAMs 
5248AA92 2D875565 
WARNING 


The NMC requires that all sets with 4 Mb DRAMs be mapped on aligned 
64 MB boundaries. This is a requirement because of the way the row 
and column addresses are generated from the incoming address. Refer to 
Section 5.4.2.1 for details. To enable this, all bank sets of 4 Mb DRAMs 
should be mapped to lower addresses than sets of 1 Mb DRAMs. 
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For example, consider a system with two bank sets of memory, where the 
first set is made up of 1 Mb DRAMs and the second is made up of 4 Mb 
DRAMs. MEMCON2, which corresponds to set 2 (the 4M bank is on the 
second memory module), should be mapped to base address <31:26> = 
000000 and MEMCONQO, which corresponds to set 0 (the 1M bank is on 
the first memory module), should be mapped to base address <31:24> = 
00000100. If the base addresses were programmed the other way, the 4M 
set would start on an unaligned 4 MB boundary. 


5.4.2.4 Ownership Bit Memory Organization and Addressing 
During normal operation, the function of O-bit memory is totally transparent to 
software. The O-bit memory serves to maintain a working record of ownership of 
each hexaword of main memory to prevent simultaneous write access by both the 
NVAX CPU and the NCA (acting on behalf of an I/O device). This is necessary 
because of the write-back protocol used by the CPU’s Bcache. 


Every hexaword in memory has one ownership bit associated with it. 16M O-bits 
are implemented, thus supporting a maximum main memory of 512 MB. 


O-bit memory is implemented on the CPU module. The NMC provides a separate 
port for this O-bit memory. The organization and addressing of this memory 

is different from that of the data memory. Eight O-bits are stored in every 
O-bit memory location. The NMC accesses eight O-bits at a time, and based 

on address<7:5>, decides which of the eight O-bits corresponds to the current 
hexaword. This scheme requires two 1M banks of 8 O-bits each to support a total 
of 16M O-bits; thus requiring six 1 Mb x 4 DRAMs. Each bank of O-bits has a 
separate CAS. The O-bit memory addresses are independent of memory address 
mapping. All O-bits are addressed using physical addresses from the NDAL. 


Address bits <7:5> are used to select a particular O-bit in the 8-bit field. Address 
bit<26> is used to select the O-bit bank. Address bits <28,27,25:8> are used to 
address locations in the DRAMs. 


Table 5-3 and Figure 5-3 illustrate the mapping scheme. 
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Figure 5-3 O-bit Port Addressing 
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Table 5-3 O-bit Port Address Mapping 


O-bit Column 
Maximum Main Memory O-bit Row Address<9:0> ' Address<9:0>? 
512 MB <28,25:17> <27,16:8> 


1 Address<26> determines the O-bit bank to be selected. If address<26> is 0, O_CAS_L<0> is asserted; 
if address<26> is 1, O_CAS_L<1> is asserted. 


? Address<7:5> are used to select one of the eight O-bits in the 8-bit field. 
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5.4.3 NMI Transactions 
The NMC supports the following transactions on the NMI: 
¢ Refresh 
e Signature read 
¢ Data read 
¢ Unmasked data write 
¢ Masked data write 


¢ Nonexistent memory access 


5.4.3.1 Refresh 


The NMC provides the mechanism to refresh the DRAMs for the data and 
ownership memories. If 1 Mb DRAMs are used, every row has to be refreshed 
once every 8 ms. If 4 Mb DRAMs are used, every row has to be refreshed 
once every 16 ms. This means that the interval between refreshes of two 
consecutive rows has to be 15.62 ps. When idle, the NMC generates a new 
refresh transaction every 13.44 ps. If a refresh request happens during a 
transaction, that transaction is completed before the refresh transaction is done 
on the NMI. The NMC allows a margin of 2.18 ps over the DRAM specification 
for this reason. The NMC has an internal refresh interval timer that initiates a 
refresh transaction every 320 NDAL cycles. The NMC also provides the refresh 
address for the DRAMs on the MA<10:0> lines. It contains a 10-bit binary 
counter, the refresh address counter, which generates consecutive addresses for 
every refresh. 1 Mb DRAMs need a 9-bit refresh address; 4 Mb DRAMs need a 
10-bit refresh address. The 1 Mb DRAMs are thus refreshed at twice the rate of 
the 4 Mb DRAMs. 


An O-bit memory refresh is done along with a data memory refresh. Refresh 
address <9:0> is mapped onto O_MA<9:0>. 


5.4.3.2 Signature Read 


A signature read transaction is initiated by doing a read to one of the memory 
signature registers, MEMSIGO-7. On these transactions, there is no O-bit access. 
Data received from the memory module is returned unchanged on the NDAL. 


5.4.3.3 Read/Write Transactions 
The NMC does quadword, octaword, or hexaword read transactions, and 
longword, quadword, octaword, or hexaword write transactions on the NMI. The 
NMI memory is quadword interleaved. Consecutive quadwords in 64-bit mode are 
read/written from/to the even and odd banks of each memory set. A transfer on 
the NMI is defined as one access from/to the DRAMs. A quadword transaction is 
one transfer, an octaword two, and a hexaword four; a longword write transaction 
is implemented as a read-modify-write. The requested data is always accessed 
first. The NMC uses page mode of the DRAMs to do a multitransfer transaction 
but it does not use page mode between two transactions. 


¢ When the NMC starts a memory read transaction on the NMI, it 
simultaneously issues an O-bit read of the ownership RAMs on the CPU 
module. If the transaction is a memory read and the O-bit is set, the 
transaction is kept pending. The read data is discarded and subsequent 
transfers are aborted. (Refer to Section 5.4.9 for details.) 
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e Ifthe NDAL transaction being serviced is an unmasked write, the write 
is done in parallel with an O-bit read. If the hexaword being written is 
found to be owned, the write is aborted after the first transfer, and is kept 
pending. (Refer to Section 5.4.9.) The first transfer can be done before it is 
known whether the location is owned because even if it is owned, since the 
NDAL transaction was an UNMASKED write, the entire hexaword will be 
overwritten as soon as the disown write comes from the owner. Therefore, it 
is all right to allow the first data transfer to take place to the memory before 
it is known whether the location is owned. 


e¢ Ifthe NDAL transaction is a masked write, a single transfer read is done 
and the O-bit is read in parallel. If the write is not owned, it is completed by 
merging the write data with the data from memory and writing it back. If the 
write data is owned, it is aborted after the read and kept pending. 


e Ifthe NDAL transaction that is being serviced is a disown write, and it is 
found to be unowned when the O-bit is read, an error is flagged but the write 
is completed. 


¢ Ifa write transaction has a completely masked transfer (all corresponding 
byte masks are equal to 0; no bytes will be written), then the CAS 
corresponding to that transfer is not asserted (that is, no write is done to 
the DRAMs). 


5.4.3.4 Nonexistent Memory Access 
If the incoming address bits <28:24> (<28:26> for 4 Mb DRAMs) do not match any 
of the programmed base addresses in the memory configuration register, the NMC 
memory interface flags an error by returning read data error NDAL cycle on a 
read or requesting a hard error interrupt (SCB offset=601g) on writes. In every 
case, the NMC responds to the NDAL transaction regardless of the fact that it 
is to nonexistent memory. This prevents errors in the NVAX CPU resulting from 
NDAL timeouts on read transactions. 


5.4.4 Error Checking for Data Memory 


The NMC implements a single bit error correcting, double bit error detecting, 
single symbol (nibble) error detecting (SEC/DED/SSD) code across 64 bits of 
memory data (Figure 5-4). On memory write transactions, the NMC generates 
ECC on the outgoing data and writes it into memory along with the data. On 
memory read transactions, the NMC reads the memory data, generates the 
corresponding ECC, compares the generated check bits with the incoming check 
bits, and generates a syndrome. If the syndrome is a 0, there is no error in the 
incoming data. If the syndrome matches a column in the code of Figure 5-4, 
there is a correctable error in the corresponding data bit. The NMC returns the 
corrected data. If the syndrome is not 0 and does not match any of the columns, 
then the error is uncorrectable. 


If, during a write transaction, there is a parity error in the NDAL data, or if 
an illegal command is received on an NDAL write data cycle, or a BADWDATA 
NDAL command (Section 3.11) is received on the NDAL, then the NMC forces 
incorrect check bits in memory. This is done by inverting the three least 
significant check bits. When, at a later stage, this data is read from memory, 
an uncorrectable syndrome of 0716 will be received. 
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Figure 5-4 SEC/DED/SSD Code Used in the NMC 


DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DDDD DCCC CCCC CDDD 
0000 0000 0011 1111 1111 2222 2222 2233 3333 3333 4444 4444 4455 5555 5555 6BBB BBBB B666 
0123 4567 8901 2345 6789 0123 4567 8901 2345 6789 0123 4567 8901 2345 6789 0012 3456 7123 


1101 0001 1101 1101 1100 1110 0011 0010 0001 1101 1101 1100 1110 0011 0010 0100 0000 0000 SO 
1010 0010 1011 1010 1011 1101 0100 0100 0010 1011 1010 1011 1101 0100 0100 1010 0000 0000 S1 
0111 1100 0110 0111 0111 0011 1000 1001 1100 0110 0111 0111 0011 1000 1001 0001 0000 0000 S2 
0001 1111 0001 0001 0001 1111 0001 0001 1111 0001 0001 0001 1111 0001 0001 1000 1000 0100 S3 
1111 1001 0010 0100 1000 0110 0111 1101 1001 0010 0100 1000 0110 0111 1101 0000 0100 0010 S4 
1111. 0110 0100 1000 0010 1001 1101 1011 0110 0100 1000 0010 1001 1101 1011 0000 0010 0001 S5 
1110 0000 1000 0010 0100 1111 1011 0111 1111 0111 1101 1011 0000 0100 1000 1000 0001 0111 S6 
0000 0000 0000 0000 0000 0000 0000 0000 1111 1111 1111 1111 1111 1111 1111 0000 0000 1111 $7* 


SO, S1, S2, S4, S5, S6 ---- Even Parity 
$3, S7 ---- Odd Parity 


*S7 Depends on Data Bits <63:32> Only. 
LJ-01321-TIO 


5.4.5 Error Checking for Ownership Bit Memory 


The NMC supports single error correction across eight O-bits in memory. An 
O-bit memory read/write accesses eight O-bits and four ECC check bits. During 
an O-bit read transaction, the NMC generates the check bits on the incoming 
O_MD<7:0> (the eight O-bits being read) and XORs them with the received check 
bits, O_MD<11:8>. If the resulting syndrome is 0, there is no error in the data. 
If the syndrome matches any of the columns in Figure 5-5, then the error is 
correctable. This code does not detect all multiple bit errors. Other than single 
bit errors the NMC detects the all Os and all 1s failures on O_ MD<11:0>. 


Figure 5-5 Single Error Correcting Code for O-bit Memory 
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5.4.6 Memory Diagnostic Support 
The NMC facilitates data memory testing in two ways - fast diagnostic mode, and 
diagnostic check bit mode. These modes can be used separately or simultaneously. 


The NMC allows memory error detection to be disabled to allow testing the check 
bit memory DRAMs. The NMC does not have to be in either of the two diagnostic 
modes for memory error dectection to be disabled. It can be disabled by setting 
MMCDSR<DIS_MEM_ERR_DETECT>. 


WARNING 


Both of these modes are for diagnostic purposes only; they should not be 
set during normal system operation. 


5-12 KA680 Main Memory System 


KA680 Main Memory System 
5.4 NMC Architectural Overview 


5.4.6.1 Fast Diagnostic Mode 
Fast diagnostic mode allows main memory to be tested at a fast rate by reading, 
writing, and comparing locations from more than one memory bank at a time. 
The NMC enters fast diagnostic mode when MMCDSR bit<FAST_DIAG_MODE> 
is set. (Refer to Table 5-8.) The implementation of fast diagnostic mode is the 
same as that in the PELE system. (Refer to the GMX specification.) When the 
NMC is in fast diagnostic mode, it sets MODE_SEL<1> to "1" on every read 
or write transaction. If at the same time the FDM second pass bit is set in 
MMCDSR (Table 5-8), MODE_SEL<0> is also set to "1". 


5.4.6.2 Diagnostic Check Bit Mode 
Diagnostic check bit mode enables software to force an arbitrary value on the 


data memory check bits. Diagnostic check bit mode can be entered by setting 
MMCDSR bit<DIAG_CKB_MODEs>. (Refer to Table 5-8.) 


When diagnostic check bit mode is set, on a memory write transaction, the check 
bit field in MMCDSR<MEM_DIAG_CKBS> is written to memory instead of the 
check bits generated by the ECC logic. The check bits received on a memory 
read transaction can be obtained by reading MMCDSR<MEM_DIAG_CKBS> or 
MMCDSR<MEM_CHECK_BITSs>, regardless of the value of MMCDSR<DIAG_ 
CKB_MODE>. 


Memory tests using diagnostic check bit mode should be run from the ROM with 
both the Pcache and Bcache off. This forces all memory reads to be of quadword 
length and is required when using diagnostic check bit mode. The NMC only 
logs the check bits corresponding to the first two transfers of a memory read 
transaction. If software wants to read the memory check bits, it should read the 
corresponding memory location and immediately follow it up with an MMCDSR 
read. This is necessary to ensure that the read check bits loaded in MMCDSR 
correspond to the correct read data. The NMC logs the diagnostic check bits on 
any memory read transactions, including the read part of a masked write. 


5.4.7 Ownership Bit Memory Diagnostic Support 


The NMC provides 4K quadword aligned registers (O-bit data registers) to access 
the O-bit memory in I/O space. These registers range from 2101 0000 - 2101 
7FFF. The NMC supports a maximum of 2M O-bit locations. These locations 

can be made up of 512 segments, where each segment consists of 4K O-bit 
locations. One of the 4K NMC O-bit data registers corresponds to 512 possible 
O-bit locations, one for each segment. The segment number can be specified in an 
O-bit address and mode register. Bits <14:3> of the addresses of MODRs along 
with the segment number in the O-bit address and mode register are used to 
specify an O-bit location. 


The address and mode register also contains a 3-bit mask field to specify a 
particular O-bit within an O-bit memory location. 


O-bit memory can be accessed in one of 5 modes - reconstruction mode, memory 
test mode with ECC, memory test mode with forced check bits, fast memory test 
mode with ECC, and fast memory test mode with forced check bits. 


To perform a diagnostic operation on O-bit memory, software should load the 
appropriate address and mode in the O-bit address and mode register (MOAMR), 
and then do a read or a write to the appropriate O-bit data register. The different 
O-bit diagnostic modes are described in the following sections. 
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5.4.7.1. Reconstruction Mode 
This mode allows software to change the value of a particular O-bit. The O-bit 
address register should be loaded with the segment address corresponding to that 
O-bit, the mask should be written, and the mode should be set to reconstruction. 
Then, software should do a write transaction to the corresponding O-bit data 
register. This would cause the NMC to do a read-modify-write transaction on 
O-bit memory location and update the O-bit. 


A read in this mode results in the entire O-bit field being returned on bits <11:0>. 


5.4.7.2. Memory Test Mode with ECC 
This mode allows software to overwrite the data part of an O-bit memory location 
without the check bits. The check bits are generated by the ECC logic. A write to 
an O-bit data register in this mode forces the data bits <7:0> to be written onto 
the corresponding O-bit memory location. 


A read in this mode results in the entire O-bit field being returned. 


5.4.7.3 Fast Memory Test Mode with ECC 
The fast memory test mode with ECC allows software to overwrite O-bit memory 
data as in memory test mode with ECC. In this mode, two locations are written 
and read. When a write is done to an O-bit I/O address in this mode, data from 
bits <7:0> and <19:12> is written to two consecutive O-bit memory locations, 
respectively. 


A read of the O-bit data register in this mode returns data from two consecutive 
O-bit locations in bits <11:0> and <23:12>, respectively. 


5.4.7.4 Memory Test Mode with Forced Check Bits 


This mode allows software to overwrite one entire O-bit memory location (eight 
O-bits plus four check bits) with any desired pattern. A write to an O-bit 
data register in this mode forces the data bits <11:0> to be written onto the 
corresponding O-bit memory location. 


A read of the O-bit data register in this mode results in a read of the 
corresponding O-bit memory location. The data that is read from O-bit memory is 
returned on bits <11:0>. 


5.4.7.5 Fast Memory Test Mode with Forced Check Bits 


The fast memory test mode with forced check bits allows software to overwrite 
O-bit memory locations as in memory test mode with forced check bits. In this 
mode, two locations are written and read. When a write is done to an O-bit 
data register in this mode, data from bits <11:0> and <23:12> is written to two 
consecutive O-bit memory locations, respectively. 


A read of the O-bit register in this mode returns data from two consecutive O-bit 
locations on bits <11:0> and <23:12>, respectively. 


5.4.8 I/O Section 


This section consists of the control and status registers (NMC_CSRs) and the 
decoders for I/O and memory addresses. It does the following operations: 


e CSR reads 
e CSR writes 
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e Clear write buffer 


The I/O space of the NMC is defined as 2101 0000 - 2101 804C, 2100 0110 (hex); 
the NMC acknowledges these I/O addresses only. 


5.4.8.1 Registers 


The NMC has 21 control and status registers (NMC_CSRs) that can be read 
or written by the CPU. These CSRs are addressed as aligned longwords only. 
Quadword reads or writes to NMC_CSRs are not supported. 


In addition, it has 4K O-bit data registers, which are quadword-aligned. 


All the NMC_CSRs are cleared on power-up reset, unless otherwise specified in 
the following description. Write operations to read-only registers do not cause any 
errors and are responded to as a normal operation; however, the operation does 
not alter any NMC register contents. Table 5—4 lists all the registers and their 
addresses. Included in this list is the clear write buffer register. 


Table 5-4 NMC Registers 


No. of 

Number Name Address Registers 
MEMCONO-7 Memory Configuration Registers 2101 8000 - 801C 8 
MEMSIG0-7 Memory Signature Registers 2101 8020 - 803C 8 
MEAR Error Address Information Registers 2101 8040 1 
MESR Error Status Register 2101 8044 1 
MMCDSR Mode Control and Diagnostic Register 2101 8048 1 
MOAMR O-bit Address and Mode Register 2101 804C 1 
MEMCON0-19 NMC Registers 2101 8000 - 804C 20 
MCWB Clear Write Buffer Register 2100 0110 1 
MODRs O-bit Data Registers 2101 0000 - 7FFF 4K 


5.4.8.1.1| Memory Configuration Registers (MEMCONO - MEMCON7) The NMC 
supports up to 8 memory sets of 16 MB with 1 Mb DRAMs and 64 MB with 4 
Mb DRAMs. Each set is associated with one software programmable register. 
Each register stores set specific information consisting of a set base address, a set 
enable, and the set signature. These registers are written following a signature 
read transaction from MEMSIGO0-7 and the computation of the base addresses. 
The following is a description of all the bit fields in these registers. 
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Figure 5-6 Memory Configuration Registers 
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MEMCONO-7 : 2101 8000 - 2101 801C 


Table 5-5 Memory Configuration Registers, MEMCONO-7 
Type, Reset 


Register Field Bits State Description 

Base Address 31 RW, 0 This read/write bit indicates that the base address 
Valid / Set programmed in bits <28:24> and the signature in bits 
Enable <2:1> are valid. This bit is cleared on powerup. It 


should be set when the base address and the signature 
are written to enable addressing of the set. In addition, 
this bit may be used by diagnostics to selectively disable 


sets. 
Unused 30:29 MBZ, 0 This field reads as 0. 
Base Address 28:24 RW, 0 Specifies the memory base address of the related set. If 


the RAM size of the set is 1 Mb, then all 5 bits are used 
in the address comparison. If the RAM size of the set 
is 4 Mb, then only bits <28:26> are used in the address 
comparison. In either case, all 5 bits can be read and 
written. See Section 5.4.2.1 and Section 5.4.2.3 for 
details on the use of the base address. 


Unused 23:3 MBZ, 0 This field reads as 0. 


RO—Read-only 
RW—Read/write 
WC—Write one-to-clear 
MBZ—Read-only, read as 0 


(continued on next page) 


5-16 KA680 Main Memory System 


KA680 Main Memory System 
5.4 NMC Architectural Overview 


Table 5-5 (Cont.) Memory Configuration Registers, MEMCONO-7 


Register Field 


Type, Reset 
Bits State Description 


Signature 


Must be 1 


2:1 RW, 0 Indicates the RAM size of the corresponding memory 
set. It has to be written to by software after doing a 
signature read of the corresponding set. 


Value Configuration 


00 Unassigned 

01 RAM size 1 Mb 
10 RAM size 4 Mb 
11 Nonexistent bank 


0 RW, 0 This bit must be set to a 1 by software. This bit, when 
clear, specifies memory controller operation to be 32- 
bit mode. when set, it indicates 64-bit mode. Since the 
KA680 only supports 64-bit memory, this bit must be set 
to a 1 by ROM software during power-up initialization 
to enable operations with memory. 


5.4.8.1.2 Memory Signature Registers (MEMSIGO - MEMSIG7) Each set of 
physical memory banks has a signature register associated with it. MEMSIGO 
corresponds to set 0, MEMSIG1 to set 1, and so on. A read from any of these 
registers causes the NMC to do a signature read transaction on the NMI to the 
corresponding set. The information returned on a read to these registers should 
be written by software to the appropriate bits in the corresponding memory 
configuration register (MEMCONO-7). For instance, a read from MEMSIGO 
would return the signature of memory set 0; this should be written by software to 
MEMCONO. 


The signature information includes the size of the DRAMs used to make up that 
memory set and the width of memory data, if the set is present in memory. If the 
set is not present, a value of FFFFFFFF (hexadecimal) is returned as read data. 
During system power-up configuration and self-test, the ROM software reads 
the signature values. Based on the signature that is returned read from each 
MEMSIG register, the corresponding MEMCON register should be programmed 
accordingly. Table 5—2 shows the two possible values that will be returned when 
a MEMSIG register is read for an existing memory set. 


5.4.8.1.3 Error Address Information Register (MEAR) When an error is logged 
by the NMC in MESR, the corresponding address and commander ID are logged 
in MEAR. This information is loaded by the first error and is not changed until 
all the error bits are cleared. These registers are read-only and have valid 
information only when an error bit is set in MESR. 
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Figure 5-7 Error Address Information Register 
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MEAR : 2101 8040 


Table 5-6 Error Address Information Register, MEAR 


Type, Reset 

Register Field Bits State Description 

Unused 31 MBZ, 0 This bit is unused and is read as 0. 

ID 30:28 RO, 0 This field contains the ID of the commander 
corresponding to the transaction in error. The ID is 
logged on NDAL errors only; memory errors do not log 
the ID. 

Error Address 27:3 RO, 0 This field contains the hexaword address at which the 
error occurred. This field is always logged. 

Error Address 2:1 RO, 0 This field indicates the quadword at which the error 
occurred. 

This field is logged on memory errors. 

This field is logged on NDAL write data parity errors, 
and on NDAL illegal write command errors. 

This field is not valid on unowned disown write errors 
and disown write timeout errors. The address is valid 
up to the hexaword only. 

This field is not valid on nonexistent memory errors. 

Error Address 0 RO, 0 This bit indicates the longword address of a memory 


transaction with an error. 
This bit is not valid on NDAL errors. 


RO—Read-only 
RW—Read/write 
WC—Write one-to-clear 


5.4.8.1.4 Error Status Register (MESR) The NMC reports error information in 
MESR. 
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Figure 5-8 Error Status Register 
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MESR : 2101 8044 


Table 5-7 Error Status Register, MESR 


Type, Reset 
Register Field Bits State Description 
Error Summary 31 RO, 0 This bit is "1" when any error is logged by the 
NMC in this register. It is clear when all the 
error bits are cleared. 
LOST_NDAL_HARD_ 30 WC, 0 This bit is set if a pending transaction times 
ERR out, a disown write is found to be unowned, 


or a nonexistent address is received on the 
NDAL, and MEAR cannot be loaded because 
of a previous error that has not been cleared. 


LOST_NDAL_SOFT_ERR = _.29 WC, 0 This bit is set if a an NDAL data parity 
error or an illegal write command is detected 
on the NDAL, and MEAR cannot be loaded 
because of a previous error that has not been 
cleared and soft error logging is enabled 
(MMCDSR<EN_SOFT_ERR_LOG> is 1). This 
bit is also logged if an NDAL data parity error 
or an illegal write data command is detected 
on the NDAL and soft error logging is disabled 
(MMCDSR<EN_SOFT_ERR_LOG> is 0). 


RO—Read-only 
RW—Read/write 
WC—Write one-to-clear 
MBZ—Read-only, read as 0 


(continued on next page) 
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Table 5-7 (Cont.) Error Status Register, MESR 


Register Field 


Bits 


Type, Reset 
State 


Description 


NDAL_RESERVED_CMD 


BAD_NDAL_ERR 


NO_ACK_ERR 


DISOWN_UNOWNED 


PEND_TRANS_TIM_OUT 


NDAL_ILLEGAL_WR_ 


CMD 


NDAL_DATA_PAR_ERR 


Unused 
MEM NXM 


MEM_SYNDROME 


MEM_HARD_ERR 


MEM_SOFT_ERR 


28 


27 


26 


25 


24 


23 


22 


21 
20 


19:12 


11 


10 
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WC, 0 


WC, 0 


WC, 0 


WC, 0 


WC, 0 


WC, 0 


WC, 0 


MBZ, 0 
WC, 0 


RO, 0 


WC, 0 


WC, 0 


This bit is set when the NMC receives a 
reserved command on the NDAL. The address 
is not logged in MEAR. 


This bit is set when the NMC receives a 
parity error on an NDAL address cycle or if it 
receives an illegal length code on an otherwise 
valid transaction. The address is not logged 
in MEAR. 


This bit is set when the NMC does not receive 
ACK_L when it returns read data on the 
NDAL. The address is not logged in MEAR. 


This bit is set if the NMC receives a disown 
write to an unowned location and MEAR can 
be loaded with the address information. 


This bit is set when a pending transaction 
times out waiting for the corresponding 
disown write, and the address can be saved in 
MEAR. 


This bit is set by the NMC when it receives a 
command other than WDATA or BADWDATA 
on the data part of an NDAL write, and 
MEAR is free to load address information. 


This bit is set if a parity error is detected 
on the NDAL during a data cycle of a write 
transaction, and if MEAR is free to load the 
address information. 


This bit reads as 0. 


This bit is set if the address received on 

the NDAL is in memory space, but does not 
match any of the programmed banks in the 
NMC memory configuration registers. It is set 
only if MEAR can be loaded with new address 
information. 


This field stores the memory error syndrome 
and is loaded when an ECC data memory 
error is detected on the NMI. The syndrome is 
logged only when the corresponding memory 
error is not logged as a lost error. 


This bit is set if an uncorrectable ECC error 
occurred during a memory read transaction, 
and if MEAR can be loaded with address 
information. 


This bit is set if a correctable ECC error 
occurred during a memory read or a masked 
write transaction, or if an uncorrectable error 
occurred during a masked write transaction, 
and if MEAR can be loaded with address 
information. 
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Type, Reset 
Register Field Bits State 


Description 


LOST_MEM_HARD_ERR- 9 WC, 0 


OB_SYNDROME 8:5 RO, 0 


OB_CORR_ERR 4 WC, 0 


OB_FATAL_ERR 3 WC, 0 


LOST_MEM_SOFT_ERR 2 WC, 0 


Unused 1:0 MBZ, 0 


This bit is set if an uncorrectable ECC error 
occurred during a memory read transaction, 
and if MEAR could not be loaded with address 
information because a previous error bit had 
been logged in MESR. 


This field stores the O-bit error syndrome 
when an error is detected in O-bit memory 
reads. The O-bit syndrome is logged only 
when the corresponding O-bit error is not 
logged as a lost error. 


This bit is set if a correctable O-bit memory 
error occurred during an O-bit read 
transaction, and if MEAR can be loaded with 
address information. 


This bit is set if the O-bit ECC logic detects a 
syndrome of 1111(binary), indicating that the 
incoming 12-bit O-bit data has an all 1s or all 
Os failure. No address information is logged. 


This bit is set when: a correctable error occurs 
during a memory read or a masked write 
transaction, a correctable error occurs on an 
O-bit read transaction, or an uncorrectable 
data memory error occurs on a masked write 
transaction, and a previous error has been 
logged in MEAR and soft error logging is 
enabled (MMCDSR<EN_SOFT_ERR_LOG> is 
1). This bit is also set when: a correctable 
error occurs during a memory read or a 
masked write transaction, a correctable error 
occurs on an O-bit read transaction, or an 
uncorrectable data memory error occurs on 

a masked write transaction and soft error 
logging is disabled (MMCDSR<EN_SOFT_ 
ERR_LOG> is 0), irrespective of the state of 
other error bits in MESR. 


This field is unused. 


5.4.8.1.5 Mode Control and Diagnostic Status Register (MMCDSR) NMC 
operating modes are controlled by bits in this register. In addition, this register 
is used for storing diagnostic status information. The following is a description of 


all the bit fields in this register. 
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Figure 5-9 Mode Control and Diagnostic Status Register 
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Table 5-8 Mode Control and Diagnostic Status Register, MMCDSR 


Type, Reset 
Register Field Bits State Description 
FAST_DIAG_ 31 RW, 0 This bit provides the mechanism for speeding 
MODE up initial diagnostic testing of memory. This bit 
indicates to the NMC that it is in fast diagnostic 
mode. 
FDM_SECOND_ 30 RW, 0 In a system with two sets of memory banks, fast 
PASS diagnostic mode has to be done in two passes. 


This bit has to be set when the second pass of 
the test has to be run. This bit is valid only when 
MMCDSR<FAST_DIAG_MODE> is set. 


DIAG_CKB_MODE 29 RW, 0 When set to 1, this bit enables the contents of 
MMCDSR <MEM_DIAG_CKBS> to be driven onto 
the check bit field of the memory data, instead of 
the normal ECC check bits. When this bit is a 0, 
the contents of MMCDSR<MEM_DIAG_CKBS> 
are ignored during memory write transactions. 
MMCDSR<MEM_DIAG_CKBS> should be valid 
when this bit is set. 


RO—Read-only 
RW—Read/write 
WC—Write one-to-clear 
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Table 5-8 (Cont.) Mode Control and Diagnostic Status Register, MMCDSR 


Register Field Bits 


Type, Reset 
State 


Description 


QBUS_ON_IO1 28 


EN_SOFT_ERR_ 27 
LOG 


FLUSH_BCACHE 26 


Unused 25 
MEM_DIAG_CKB 24:17 


MEM_CHECKBITS 16:9 


TIMEOUT_ 8:7 
SCALER 


RW, 0 


RW, 0 


RO, 0 


RW, 0 
RW, 0 


RO, 0 


RW, 0 


This bit is used by the NMC to indicate on which CP- 
bus the Q22-bus interface (CQBIC) resides. THIS 
BIT IS CLEARED ON POWERUP AND MUST NOT 
BE CHANGED. 


When this bit is a0, NDAL and memory-related soft 
errors are detected but no information is logged in 
MEAR and MESR, and S_ERR_L is not asserted. 

If the error happened on the NDAL, MESR<LOST_ 
NDAL_SOFT_ERR> is logged; if the error happened 
in memory, the MESR<LOST_MEM_SOFT_ERR> 

is logged. When this bit is 1, all the soft errors 

are logged normally as described in the description 
of MESR, and S_ERR_L is asserted whenever a 
correctable error occurs. This bit does not affect 
hard error logging. 


When this bit is set by software, the NMC asserts 
the CPU_WB_ONLY signal on the NDAL, which 
informs the NVAX CPU to refrain from performing 
non-writeback transactions on the NDAL. The 
purpose of this bit is to allow the Bcache to be 
flushed without creating excessive NDAL traffic 
that might otherwise adversely affect the latency of 
devices on CP1 and CP2 (namely, the Q22-bus). 


This field is ignored on memory write transactions 
when diagnostic check mode (MMCDSR<DIAG_ 
CKB_MODE>) is cleared. During diagnostic check 
bit mode, the bits in this field are written to memory 
instead of the check bits generated by the ECC logic. 


A read of MMCDSR returns the check bits 
corresponding to the first transfer of a memory 
read transaction that happened prior to this NMC_ 
CSR read. This field is loaded on memory reads or 
masked write transactions. 


This field contains the memory check bits 
corresponding to the second transfer of a memory 
read transaction that happened prior to this NMC_ 
CSR read. This field is loaded on memory reads or 
masked write transactions. 


This 2-bit field is used as a prescaler to the disown 
write timeout counter. 


Value Timer Count us (36 ns) ps (42 ns) 
00 2600 93.6 109.2 

01 1600 57.6 67.2 

10 800 28.8 33.6 

11 400 14.4 16.8 


(continued on next page) 
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Table 5-8 (Cont.) Mode Control and Diagnostic Status Register, MMCDSR 


Register Field 


Bits 


Type, Reset 
State 


Description 


DIS_MEM_ERR 


REF_INT_SEL 


FRC_WRONG_ 
PAR_DATA_OUT 


FRC_WRONG_ 
PAR_ADDR_IN 


FRC_WRONG_ 
PAR_DATA_IN 
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6 


RW, 0 


RW, 0 


RW, 0 


RW, 0 


RW, 0 


When this bit is 1, memory error detection and 
correction is disabled. All memory error related 
logging in MEAR and MESR is disabled. S_ERR_ 
L does not assert on correctable errors in memory 
data; S_ERR_L does not assert on uncorrectable 
errors in the read data of a masked write. A read 
data error response is not returned on the NDAL 
when uncorrectable errors occur in memory read 
data. 


When this bit is 1, the NMC uses an alternate 
refresh interval for use in conjunction with NDAL 
cycle times longer (slower) than 42 ns. Because 
the KA680 and KA680 CPU modules operate at 42 
ns NDAL cycle times or faster, this bit should not 
be set by software because it will cause excessive 
memory refresh cycles and subsequently reduce 
system performance. 


When set to 1, this bit forces the NDAL parity 
generator to generate incorrect parity on the 
command and ID field of a read data return cycle. 
This will cause the commanders to not ACK the 
response and timeout, waiting for the appropriate 
data. The wrong parity is forced for one NMC 
responder transaction only. This bit is self-clearing; 
it is always read as 0. This bit is for test purposes 
only and should not be set during normal system 
operation. 


When set to 1, this bit forces the NDAL parity 
generator in the NMC to generate incorrect parity 
on the command and ID field of an address cycle 
addressed to it. This results in the NMC detecting 
incorrect parity on incoming transactions, thus 
causing it to not ACK the commander and assert S_ 
ERR_L. The wrong parity is forced for one NDAL 
transaction (not a NOP) only. This bit is self- 
clearing. It is always read as 0. This bit is for test 
purposes only and should not be set during normal 
system operation. 


When set to 1, this bit forces the NDAL parity 
generator to generate incorrect parity on the 
command and ID field of a write data. This causes 
the NMC to respond to the cycle with ACK_L, but 
assert S_ERR_L and force incorrect check bits in 
memory data. The wrong parity is forced for one 
NDAL data cycle only. This bit is self-clearing; it 
is always read as 0. This bit is for test purposes 
only and should not be set during normal system 
operation. 
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Table 5-8 (Cont.) Mode Control and Diagnostic Status Register, MMCDSR 


Type, Reset 
Register Field Bits State Description 
DIS_REFRESH 1 RW, 0 This bit, when set to 1, disables memory refresh 


transactions, irrespective of the state of MMCDSR 
<FRC_REFRESH>, the force refresh bit. It also 
clears the refresh interval and address counters 
to 0. This functionality has been added for test 
purposes only and should not be used in normal 
system operation. 


FRC_REFRESH 0 RW, 0 When this bit is cleared to 0, the refresh control logic 
behaves normally and refreshes are done on the NMI 
when the refresh interval timer overflows. When 
this bit is set to 1, it forces the memory interface of 
the NMC to do continuous memory refreshes as long 
as there are no requests for memory transactions. 

If the memory is requested to do a read, write, or 
signature read transaction, the stream of memory 
refreshes is interrupted. 


5.4.8.1.6 O-bit Address and Mode Register (MOAMR) This register, along with 
the O-bit data register, facilitates initialization and testing of O-bit memory. This 
register stores the address and mode of operation. 


Figure 5-10 O-bit Address and Mode Register 
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Table 5-9 O-bit Address and Mode Register, MOAMR 


Type, Reset 

Register Field Bits State Description 

Unused 31:17 MBZ, 0 This field is read as 0. 

Ignore O-bit Mode 16 RW,0 Setting this bit causes the memory controller 
to ignore the state of the ownership bits when 
processing memory transactions. This bit is for 
diagnostic purposes only and should not be set under 
normal conditions. 

Disable O-bit 15 RW,0 Setting this bit causes the memory controller to 

Errors ignore any ECC errors in the O-bits when processing 
memory transactions. This bit is for diagnostic 
purposes only and should not be set under normal 
conditions. 

O-bit Segment 14:6 RW, 0 This field contains the segment address 

Address corresponding to the O-bit to be accessed. 

O-bit Mask 5:3 RW, 0 This field contains the O-bit mask. It is used in 
reconstruction mode to specify the O-bit to be 
accessed. 

O-bit Operation 2:0 RW, 0 This field indicates the mode of operation on a read 


Mode 


or write of the O-bit data registers. The following is 
the assignment of bits<2:0> in this field. 


Value O-bit Mode 


000 Reconstruction mode 

001 Unassigned 

010 Memory test mode 

011 Fast memory test mode 

100 Unassigned 

101 Unassigned 

110 Memory test mode with forced check bits 

111 toa memory test mode with forced check 
its 


RO—Read-only 


RW—Read/write 


WC—Write one-to-clear 
MBZ—Read-only, read as 0 
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5.4.8.1.7 O-bit Data Registers (MODRs) There are 4K O-bit data registers; each 
register corresponds to one of 512 O-bit memory locations. The NMC uses the 
segment number provided in the O-bit address and mode register to determine 
the appropriate O-bit location addressed. A read or write from/to an O-bit data 
register causes the NMC to do a read/write from/to the O-bit memory location 
whose segment number corresponds to the value in the O-bit address and mode 


register. 
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Figure 5-11 O-bit Data Registers 


3130 29 28 27 26 25 24 23 22 21 2019181716151413121110 9 8 7 65 4 3 2 1 0 


ah 


Reg ey od 


O-BIT FIELD 0 


O-BIT FIELD 1 
MODR : 2101 0000 - 2101 7FFC 


Table 5-10 O-bit Data Registers, MODR 
Type, Reset 


Register Field Bits State Description 
Unused 31:24 MBZ, 0 This field is read as 0. 
O-bit Field 1 23:12 RW, 0 This field is used in fast memory test only. It 


contains the O-bit field (O-bits + check bits) for 
the second O-bit location to be read/written in fast 
memory test mode. 


When the force check bits mode is disabled in the 
O-bit address and mode register, only bits <19:12> of 
this field are valid. 


RO—Read-only 
RW—Read/write 
WC—Write one-to-clear 
MBZ—Read-only, read as 0 


(continued on next page) 
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Table 5-10 (Cont.) O-bit Data Registers, MODR 


Type, Reset 
Register Field Bits State Description 
O-bit Field 0 11:0 RW, 0 This field contains the value for the O-bit field to 


be used in the first part of a fast O-bit test mode 
transaction, memory test mode, and reconstruction 
mode. 


A read of MODRs returns the entire O-bit location in 
fast memory test, memory test, and reconstruction 
mode. 


A write to this field in reconstruction mode requires 
valid data in the appropriate O-bit only. A write to 
this field in O-bit memory test or fast O-bit memory 
test mode with the force check bits mode disabled 
requires valid data in bits <7:0> only. A write to this 
field in O-bit memory test or fast O-bit memory test 
mode requires valid data in all 12 bits. 


5.4.8.1.8 Clear Write Buffer Register (NMC_CSR20) The clear write buffer 
register address, 2100 0110, is in the NVAX CPU IPR address range. It is 
longword-aligned. A read or write to this register is required to flush any CPU 
write buffers in the NMC. The NMC buffers up CPU writes in its CPU_QUE 
and CPU disown writes in WB_QUE. Since the CPU_QUE of the NMC is one 
deep and WB_QUE is given the highest priority by the NMC, all writes and 
write-backs from the CPU that happened before a clear write buffer transaction 
on the NDAL are completed in memory before the clear write buffer is serviced 
by the NMC. Thus, the NMC does not need to take any special action on a clear 
write buffer transaction. A read from NMC_CSR20 returns all zeros as the data; 
a write does nothing. 


5.4.9 NMC Transaction Handling 


The previous sections in this chapter described the architecture and organization 
of four major blocks in the NMC: the NDAL interface, the memory interface, the 
O-bit interface, and the I/O interface. This section describes the fifth block in the 
NMC, the transaction handler. Figure 5—12 illustrates the organization of these 

five blocks. 
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Figure 5-12 NMC Block Diagra 
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The transaction handler consists of an internal arbiter. The data path of the 
transaction handler includes a current transaction buffer and one pending 
transaction buffer. These blocks are described in greater detail in the following 
sections. 


5.4.9.1 NMC Internal Arbitration 


Transactions loaded into the IN_QUEs of the NDAL interface of the NMC are 
selected for servicing by an internal arbiter. This internal arbiter can get up to 
four requests, one from each of the three NWB_QUEs, and one from WB_QUE. 
In the absence of memory accesses from the Q22-bus, the WB_QUE is given 
the highest priority, and the three NWB_QUEs are given equal priority; they 
are serviced in round-robin. When Q22-bus devices are accessing main memory, 
I02_QUE is given a higher priority over WB_QUE (which helps reduce Q22-bus 
latency), and transactions from IO1_QUE and CPU_QUE are not selected unless 
they are marked. 
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5.4.9.2 Transaction Handler Datapath 


When a transaction is selected for processing by the NMC, the information from 
the corresponding NMC’s IN_QUE entry is loaded into the current transaction 
buffer, CUR_BUF. CUR_BUF contains all the information that an IN_QUE entry 
contains. 


When a disown write transaction is received on the NDAL, and there is a 
transaction pending to the same hexaword in one of the NWB_QUEs, the address 
information and data (writes only) for that transaction are loaded into a "pending 
buffer"- PEND_BUF, and the corresponding pending, valid, and mark bits for that 
entry are cleared. 


5.4.10 NMC Transactions 


This section describes how the various transactions are handled by the NMC. 


5.4.10.1 Ownership Read 


When an ownership read transaction is received in CUR_BUF, the data read and 
the O-bit read are started in parallel. 


If the corresponding O-bit is not set, indicating that the hexaword can be owned 
by the requesting commander, the hexaword of data is loaded into the OUT_ 
QUE as it is received from memory with the requested quadword loaded first. 
The O-bit is set by the memory interface after it checks the memory data for 
errors. The O-bit is only set when there are no uncorrectable errors in the 
requested memory data or the O-bit field. As a performance enhancement, the 
O-bit interface unconditionally sets the O-bit after every OREAD transaction; if 
later a memory data uncorrectable error is found, the original state of the O-bit is 
restored. The corresponding IN_QUE entry is cleared as soon as the transaction 
handler determines that the hexaword is not owned. 


If the corresponding O-bit is set, indicating that the hexaword is owned by 
another device, the "pending bit" is set in the appropriate NWB_QUE, the 
pending timer for that queue is started, and the read is aborted on the NMI. 


5.4.10.2 Memory Read 


The flow for the memory read is the same as that of the OREAD, the only 
difference being that the O-bit is not set at the end of the read. 


5.4.10.3 Memory Write 


On a memory write transaction, the data write and the O-bit read are done in 
parallel, instead of reading the O-bit first and doing the write only if the O-bit is 
cleared. Starting the write and the O-bit read in parallel saves time on writes 
that are not owned. 


If the hexaword is not owned (the corresponding O-bit is clear), the write is 
completed. The corresponding IN_QUE entry is cleared as soon as the transaction 
handler finds out that the transaction is not owned. 


If the hexaword is owned (the corresponding O-bit is set), the write is aborted 
(after one transfer on an unmasked write, or after the read part of a masked 
write), the corresponding pending bit is set, and the pending timer is started. 

At this point, some of the data corresponding to the aborted write is written to 
memory. This results in an apparent memory incoherency. However, since the 
corresponding hexaword is owned by some other node, the data in memory is stale 
anyway and has to be updated. The disown write flow ensures the coherence of 
memory. 
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5.4.10.4 Disown Write 


Disown writes can be quadword or hexaword writes. A quadword disown write 
may be a write unlock from the NCA on behalf of an I/O device, or it could be 
from the CPU (when the Bcache is off or in error transition mode). The CPU 
may also do a quadword disown write instead of a hexaword disown if it has 
seen one of the other commanders do a hexaword write to the same location; 
in this case, it masks out all the data. The reason for this optimization is as 
follows: if the CPU owns a hexaword of memory, and it sees on the NDAL a 
hexaword write transaction (from the NCA) to that location, then according to 
NDAL protocol it must relinquish ownership of the hexword via a disown write 
transaction (WDISOWN). Recall, however, that the hexaword write from the 
NCA will be queued up in the NMC, waiting for the WDISOWN from the CPU. 
Since whatever value the CPU specifies in the WDISOWN would be immediately 
overwritten by the NCA’s pending hexaword write, the CPU saves three NDAL 
cycles by only writing a quadword of data with the WDISOWN transaction. 


When the NMC’s transaction sequencer receives a disown write, it checks the 
state of the pending bits in the NWB_QUEs to see if there are any pending reads 
or writes to that hexaword. 


If there are no pending transactions, the memory write and an O-bit read are 
started in parallel. If the hexaword is not owned, an error is flagged but the data 
write is completed. If the O-bit is set, the write is completed and the O-bit is 
cleared. The corresponding IN_QUE entry is cleared as soon as the O-bit read is 
complete. 


If a write is pending to the same hexaword, the IN_QUE entry corresponding to 
the pending write is cleared by the transaction handler. Merging of data occurs 
according to the byte masks of the pending write, and the data is written to 
memory. The data in memory is overwritten by the merged data, and memory 
coherence is preserved. 


If the pending transaction is a read, and the disown write is a hexaword, read 
data is returned as the disown write is written to memory. If the disown write 
is a quadword, the read is done from memory, and the write data is merged with 
the appropriate quadword and returned on the NDAL. If the pending transaction 
is anormal memory read, the O-bit is cleared at the end of the disown write. If 
the pending transaction is a ownership read, the O-bit is set at the end of the 
disown write if no uncorrectable memory errors have been found in the requested 
quadword. 


5.4.11 I/O Transactions 


The NMC supports I/O reads or writes to its internal registers only. No ownership 
protocol is supported on I/O addresses. Ownership reads or disown writes to I/O 
space are treated as normal reads and writes. 


5.4.12 NMC Error Handling 


Errors in the NMC can be of two types—NDAL-related errors and memory-related 
errors. These are described in the following tables. 
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Table 5-11 NDAL-related Errors and NMC Responses 


Description of Error 


Specific Situation 


Action Taken by NMC 


NMC detects a parity 
error on an NDAL cycle 


NMC detects an illegal 
length on an NDAL 
address cycle to its 
address space 


NMC detects a reserved 
command on an NDAL 
cycle 


Illegal write data CMD 


No acknowledgement 
when requested read 
data is returned by the 
NMC 


Pending transaction 
times out waiting for 
disown write 


Presumed address cycle, 
not an NMC write data 
cycle 


Presumed data cycle 
on a write; address has 
been received previously 


Presumed address cycle 


Presumed address cycle 


Data cycles on writes 


IREAD, DREAD 


OREAD 


Write 


Read 
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Soft error interrupt on reads, both 
hard and soft error interrupt on writes; 
MESR<BAD_NDAL_ERR> logged. No 
address information is logged. 


Soft error interrupt; logs the error 

in MESR<NDAL_DATA_PAR_ERR>. 
Memory write is done and incorrect 
check bits are forced in memory data. 
CSR writes are aborted, no write is 
done, soft error interrupt. Quadword 
address and commander ID are logged 
in MEAR. 


ACK_L not asserted; S_ERR_L 
asserted; MESR<BAD_ NDAL_ERR> 
logged. No address information is 
logged. 


Soft error interrupt on reads to NMC, 
hard error interrupt on writes to NMC; 
MESR<RESERVED_CMD> is logged. 
No address information is logged. 


Write for the specified length is done; 
incorrect check bits are loaded in 
memory for the quadword with the 
incorrect command; soft error interrupt. 
Error logged in MESR<ILLEGAL_WR_ 
CMD>. On CSR write transactions, a 
soft error interrupt is requested, and 
the write is aborted. Quadword error 
address and commander ID are logged. 


Soft error interrupt is requested; logs 
the error in MESR<NO_ACK_ERR>. 
No address logged; the corresponding 
commander should log the address 
information. All read data is returned. 


Soft error interrupt is requested; logs 
the error in MESR<NO_ACK_ERR>. 
No address information is logged; the 
corresponding commander should log 
address information. All read data is 
returned. Does not affect the setting of 
the O-bit. 


Hard error interrupt is requested; logs 
the error information in MESR<PEND_ 
TRANS_TIM_OUT>. Hexaword address 
and ID are logged. Transaction is 
aborted. 


Read data error transaction returned 
on requested quadword. Log the 
error information in MESR<PEND_ 
TIM_OUT>. Hexaword address and 
commander ID are logged. 
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Table 5-11 (Cont.) NDAL-related Errors and NMC Responses 


Description of Error Specific Situation 


Action Taken by NMC 


Disown write to an WDISOWN 
unowned location 
Nonexistent memory Read 
address 

Write 


Hard error interrupt requested. Do 
the write. Pending transactions 

will be completed. Log the error 

in MESR<DISOWN_UNOWNED>. 
Hexaword address and commander ID 
are logged. 


Read data error returned on requested 
data. Error logged in MESR<MEM_ 
NXM>. Hexaword address and 
commander ID are logged. 


Hard error interrupt is requested. 
Error logged in MESR<MEM_NXM>. 
Hexaword address and commander ID 
are logged. 


Table 5-12 Memory-related Errors and NMC Responses 


Description of Error Specific Situation 


Action Taken by NMC 


NMC detects an 
uncorrectable data 
memory error 


Owned reads, 
Owned masked writes 


Memory reads (not 
owned) 


OREADs (not owned) 


Masked memory disown 
writes 


Masked memory writes, 
no disown (not owned) 


The NMC does not flag any errors and does not log 
any bits in this case. A memory transaction to a 
location that is found to be owned is not completed 
until the corresponding disown write happens. The 
data in memory is stale, and the disown write may 
overwrite it, thus writing correct data over the stale 
data with errors. No error will be logged in this 
case. If the disown write does not overwrite this 
location (quadword disown), then the uncorrectable 
data memory error is found again, and will be 
flagged and logged this time. 


Read data error is returned on that transfer; 
subsequent transfers are aborted. Error is logged in 
MESR<MEM_HARD_ERR>. Longword address is 
logged. 


Read data error is returned on that transfer; 
subsequent transfers are aborted. Error is logged 
in MESR<MEM_HARD_ERR>. Longword address 
is logged. O-bit not set if error occurred on the 
requested quadword. 


S_ERR_L is asserted; the write corresponding to 
that transfer does not happen. If a read is pending 
to that location, RDE is returned on the read. In 
this case, no error interrupt is requested. Error is 
logged in MESR<MEM_SOFT_ERR>. Longword 
address is logged. 


Soft error interrupt is requested; the write 
corresponding to that transfer does not happen. 
Error is logged in MESR<MEM_SOFT_ERR>. 
Longword address is logged. 


(continued on next page) 
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Table 5-12 (Cont.) Memory-related Errors and NMC Responses 


Description of Error 


Specific Situation 


Action Taken by NMC 


NMC detects a fatal 
O-bit error 


NMC detects a 
correctable data memory 
error 


NMC detects a 
correctable error in 


O-bit field 


All transactions 


Memory reads 


Masked memory writes 


Read, writes 


An O-bit fatal error is flagged when the NMC 

does an O-bit read transaction that has an error 
syndrome of 1111 (binary). This syndrome is 
received if the O-bit read returns all Os or all 1s 

in the 12-bit field. When this error happens, the 
NMC requests a hard error interrupt, and logs 
MESR<OB_FATAL_ERR> bit. No address is logged, 
and the transactions are completed as if there were 
no error. 


Data is corrected and returned on the NDAL. Soft 
error interrupt requested. Data is not changed in 
memory. Error is logged in MESR<MEM_CORR_ 
ERR>. Longword address is logged. 


Soft error interrupt is requested; read data is 
corrected and merged with write data and retired 
to memory. Error is logged in MESR<MEM_CORR_ 
ERR>. Longword address is logged. 


Soft error interrupt is requested. Error is logged 
in MESR<OB_CORR_ERR>. Hexaword address is 
logged in MEAR. 


5.4.13 NDAL Arbitration 


The three nodes on the NDAL request the bus whenever they have a transaction 
to perform on the NDAL. A commander could initiate a transaction or a responder 
could be responding to a pending transaction. The NMC is a responder only, the 
NVAX CPU is a commander only, and the NCA can be both a commander and 
responder, although not during the same transaction. The NMC contains the 
arbiter (N_ARB) for the NDAL. Arbitration is done in parallel with data transfer 
cycles using a set of lines dedicated specifically for arbitration. They are detailed 
in this section. 


The NMC request is asserted a cycle before quadword read data is loaded into the 
OUT_QUE. The N_ARB priority scheme is discussed in this section. 


When WB_QUE is full, the N_ARB does not grant the bus to any node except the 


NMC. 


When a non-writeback transaction is recieved by the NMC, the WB_ONLY signal 
corresponding to that commander is asserted. N_ARB does not grant the bus to 
that node for the next cycle. 


The NMC is given the highest priority by N_ARB. The two I/O ports of the NCA 
are given the second priority; they are serviced with a round-robin scheme. The 
NVAX CPU has the lowest priority. Table 5-13 indicates the priority of the NDAL 


arbiter. 


Table 5-13 NDAL Arbitration Priority 


Priority Node 
1 NMC 
2 IO1, 102 
3 CPU 
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The NMC request is never ignored by N_ARB. If no node requests the NDAL, the 
NMC is given the grant (it is the default bus master of the NDAL). 


5.5 NMC Initialization 


5.5.1 Internal Register States 


The following list describes the state of each NMC_CSR when NDAL_RESET_L 
asserts. 


Memory configuration registers (MEMCONO - MEMCON7) : 
These registers are cleared to 0. 


Memory signature registers (MEMSIGO - MEMSIG7) : 
These registers are virtual registers in the NMC and have no power-up value. 


Error address information register (MEAR) : 
This register is cleared to 0. 


Error status register (MESR) : 
This register is cleared to 0. 


Mode control and diagnostic status register (MMCDSR): 
This register is cleared to 0. 


O-bit address and mode register (MOAMR): 
This register is cleared to 0. 


O-bit data registers (MODRs): 
These registers are virtual registers in the NMC and have no value on reset. 


5.5.2 Counter States 


The following list describes the state of all the counters in the NMC when NDAL_ 
RESET _L asserts. 


Pending transaction timers : 
These timers are cleared to the ZERO state: the prescaler is also cleared to 0 
so that the timeout interval is 2600 cycles. 


Refresh interval timer: 
This timer is cleared to the ZERO state. 


Refresh address counter: 
This counter is cleared to 0 so that the first refresh address after NDAL_ 
RESET_L deasserts is 0. 


5.6 Memory Subsystem Organization 
The NMC supports a 64-bit memory interconnect. 


5.6.1 64-bit Interconnect 


The memory subsystem consists of up to four memory modules having up to four 
72-bit banks each (64 bits data and 8 bits ECC). There can be a total of up to 16 
banks of memory. The memory banks are 2-way interleaved. This requires that 
each module has an even number of banks. The following discussion refers to 
bank pairs. The module organization is shown in Figure 5-138. 
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Up to 512 MB of ECC memory can be supported by the KA680 when using 
memory modules populated with 4 Mb DRAMs. KA680 memory systems can 
also contain a mixture of 4 Mb and 1 Mb based memory modules, although the 
maximum memory will be lower than 512 MB when one or more 1 Mb based 
modules are used. 


The NVAX memory space is mapped to the physical memory using the memory 
configuration registers in the NMC. The NMC requires that all bank pairs with 
4 Mb DRAMs be mapped on aligned 64 MB boundaries. To enable this, all bank 
pairs with 4 Mb DRAMs should be mapped to addresses lower than the 1 Mb 
DRAMs. 


5.6.2 GMX Chip 


5-36 


Each memory module has four transceiver chips (GMX) that perform data 
multiplexing between the NMI bus and the DRAM array. The GMX chips 
also perform other functions such as memory signature read and fast memory 
diagnostics. 


Each GMX has four data bus ports—BMDOA<19:0>, BMDOB<19:0>, 
BMD1A<19:0>, and BMD1B<19:0>. On the MS690 memory modules, all the 
GMxX’s BMD lines are connected to one bank of DRAMs each. Thus, 64-bit MS690 
memory boards have four GMX chips to handle the 72 data and ECC bits. 
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Figure 5-13 Memory Organization with 64-bit Interconnect 
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The I/O subsystem is controlled by the NVAX I/O adapter chip (NCA). The NCA 
is a 339-pin custom VLSI chip packaged in a PGA package. The NCA functions 
as a bidirectional bus adapter between the NDAL and two CVAX-compatible 
peripheral buses : the CP1-bus on port 1 and the CP2-bus on port 2. On the 
NDAL, the NCA supports the NVAX CPU chip and the NVAX memory controller 
chip (NMC). On the CP1-bus and CP2-bus, the NCA supports the shared host 
adapter chip (SHAC), the second generation Ethernet controller (SGEC), the 
system support chip (SSC), and the CMOS Q22-bus adapter chip (CQBIC). 


6.1 NCA Overview 


The NCA provides a bidirectional interface between the NDAL and two CVAX- 
compatible peripheral (CP) buses: the CP1-bus on NCA port 1 and the CP2-bus 
on NCA port 2. The NVAX CPU, the NVAX memory controller (NMC), and the 
NCA are connected to the NDAL bus. 


The CP1 and CP2 are CVAX-compatible peripheral (CP) buses for the system’s 
DMA I/O devices and program-controlled I/O devices. 


The NCA supports the CQBIC, the SSC, the SGEC, and two SHACs on the CP 
buses. 


6.2 I/O System Configuration 


The I/O bus configuration used on the KA680 is shown in Chapter 1. In this 
configuration, the Q22—bus, SSC, and the console firmware ROMs reside on the 
CP2-bus of the NCA. They are isolated in this manner in order to minimize the 
latency incurred when the KA680 is responding to Q22-bus transactions as a 
slave. 
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6.3 NCA Chip Architecture 


The NCA serves as a bidirectional adapter between the NVAX DAL (NDAL) and 
two CVAX peripheral buses (CP1 on port 1 and CP2 on port 2). The four major 
functional blocks of the NCA chip are listed below: 


¢ NDAL interface (Section 6.3.2) 

¢ CP1 interface (Section 6.3.3) 

¢ CP2 interface (Section 6.3.3) 

¢ Registers (Section 6.3.4) 

Figure 6-1 shows the organization of the NCA. 


The following sections describe each functional block and its interactions, and the 
NCA addressing. A discussion on error handling is also included at the end of 
this section. 


The NDAL and CP1 and CP2 interface sections are further divided into master 
and slave subsections. Information transfer between the different sections of 

the NCA occurs via two buses—TO_NDAL and TO_CDAL. TO_NDAL transfers 
information to the NDAL interface from both CP-bus interfaces. The TO_CDAL 
transfers information from the NDAL interface to other sections of the chip. In 
addition, there are two more buses : TO_CP1 and TO_CP2, which transfer NVAX 
initiated I/O transactions information to the respective CP-bus interface. 
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Figure 6-1 NCA Block Diagram 
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TERMINOLOGY 


For the rest of this manual, the following terms are commonly used to 
refer to NCA ports. 


¢ CP1—means port 1 of the NCA where CP1-bus is connected 
¢ CP2—means port 2 of the NCA where CP2-bus is connected 
¢ CP—means both CP1 and CP2 


6.3.1 NCA Addressing 


The NCA responds to addresses on the NDAL that access devices on the CP1-bus, 
CP2-bus, or internal registers in the NCA. These addresses and their destinations 
are summarized in Table 6-1. 


Table 6—1 NCA Addresses 


Address Range (hex) Destination 

2000 0000 - 2000 3FFF CP2 device addresses 

2000 4000 - 2000 FFFF CP1 device addresses 

2001 0000 - 20FF FFFF CP2 device addresses 

2100 0000 - 2100 005F Not Acknowledged 

2100 0060 - 2100 0063 SRM ICCS Register 

2100 0064 - 2100 0067 SRM NICR Register 

2100 0068 - 2100 006B SRM ICR Register 

2100 O006C - 2100 OOFF Not Acknowledged 

2100 0100 - 2100 010F Interrupt Vector Read addresses 

2100 0110 - 2101 FFFF Not Acknowledged 

2102 0000 - 2102 001F NCA internal registers 

2102 0020 - 2102 FFFF Not Acknowledged 

2103 0000 - 2103 FFFF CP2 device addresses if IO2_ID_EN is set, else Not 
Acknowledged 

2104 0000 - 27FF FFFF CP1 device addresses 

2800 0000 - 2FFF FFFF CP2 device addresses 

3000 0000 - 3FFF FFFF CP2 device addresses if IO2_ID_EN is set, else Not 
Acknowledged 


6.3.2 NDAL Interface 


The NDAL interface section is made up of the NDAL master and slave interface 
subsections. 


6.3.2.1 NDAL Slave Interface 


The NCA’s NDAL slave interface continuously monitors the NDAL for 
transactions addressed to the NCA. Parity is checked on the NDAL<63:0>, 
CMD_H<3:0>, and ID_H<2:0> for valid parity. If there is no parity error and the 
transaction is addressed to the NCA, the NCA acknowledges with the assertion of 
ACK_L. The information is then placed into one of the following queues : IO_RW, 
CP1_RBUF, or CP2_RBUF. IO_RW queue is described below and the other two 
buffers are described in their respective sections. 


6-4 KA680 I/O Subsystem 


KA680 I/O Subsystem 
6.3 NCA Chip Architecture 


IO_RW - IO_RW is a 4-entry deep queue that holds the transactions 
addressed to the NCA I/O space ports 1 and 2. Each entry contains quadword 
address, quadword data (for I/O write only), a valid bit, a port ID (CP1 

or CP2), and a transaction token. The IO_RW is a common pool of I/O 
transactions for both port 1 and port 2. An I/O transaction is stored into 

the IO_RW queue whenever an entry becomes "empty." The CP1 and CP2 
interfaces examine the IO_RW entries to determine if there is a pending 
transaction for their ports. This is accomplished by the valid bit, the port 
ID, and the transaction token. Since the IO_RW is 4-entry deep, two bits 
are maintained as the token. The token of each entry is compared with the 
expected token of each CP port controllor. When there is a match in any one 
of the four entries, the port controllor initiates the transaction on the bus. By 
doing so, CP1 and CP2 are operated independently and the utilization of the 
queue is optimized. The expected token of CP1 (CP2) is incremented (mod 4) 
after each transaction. 


When the IO_RW queue has four valid entries (queue is full), the IO1_ 
SUPPRESS_L signal is asserted to the NMC, which asserts the CPU_ 
WB_ONLY to the NVAX CPU. The NVAX CPU is then expected to perform 
WDISOWN operations only on the NDAL (that is, the NVAX CPU will not 
drive any transactions on the NDAL other than WDISOWNs). This prevents 
the NCA IO_RW queue from overflowing. 


Note 


The NCA supports only longword and quadword transactions to the I/O 
space. 


6.3.2.2 NDAL Master Interface 


The NDAL master interface is responsible for initiating DMA read and write 
operations on the NDAL, as well as returning I/O read data to the CPU. The 
information for all NDAL master transactions comes from the CP1, CP2, and 
register sections. The following is the list of transactions and the buffers from 
which the transactions are initiated: 


CP1 DMA write (CP1_WBUF) 

CP1 DMA read (CP1_MEMRD) 

CP1 I/O read data return (CP1_IORBUF) 
CP2 DMA write (CP2_WBUF) 

CP2 DMA read (CP2_MEMRD) 

CP2 I/O read data return (CP2_IORBUF) 
CSR read data return (TRANSMIT BUFFER) 


The master control block in the NDAL master interface contains the bus interface 
and arbitration units. The bus interface unit requests NDAL bus ownership when 
any of the NDAL master buffers contains valid information, and sequences the 
transaction when the NCA is granted the ownership of the NDAL. 
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The arbitration unit follows a fixed priority for initiating transactions on 
the NDAL when more than one transaction is pending. The CP1 and CSR 
transactions are arbitrated in the following priority, from highest to lowest : 


1. CP1 memory read 

2. CP1 memory write 

3. CP1 I/O read data return 

4. CSR and SRM interval timer read data return 


The CP2 transactions are arbitrated in the following priority, from highest to 
lowest : 


1. CP2 memory read 
2. CP2 memory write 
3. CP2 I/O read data return 


Note 


The NCA only initiates one transaction for each NDAL bus grant; 
however, it may retain bus ownership for additional NDAL cycles to 
return I/O, CSR, or VAX interval timer read data after completing the 
original transaction. This is to prevent the lower priority transaction from 
starving. 


6.3.3 CP1 and CP2 Interface 


Because both the CP1 and CP2 interfaces are copies of each other, the two 
interfaces will be discussed as CP. 


The CP interface section is made up of the master and slave interface subsections. 


6.3.3.1. CP Master Interface 


The CP master interface is responsible for initiating I/O read and write operations 
on the CP buses. Address and/or data information for these transactions comes 
from the IO_RW queue of the NDAL slave section. 


CP_IORBUF - CP_IORBUF is a single entry buffer that holds I/O read data 
returned from the CP bus. It holds up to a quadword of data and has a valid bit. 
When the buffer is valid, CP_LIORBUF sends a request to the NDAL master 
arbitration unit. When the transaction is granted to the CP_IORBUF, the 
quadword data, the command bits, the ID bits, and the parity bits are driven 
onto the NCA’s internal TO_NDAL bus and then onto the NDAL when IO1_ 
GRANT_L is asserted by the NMC. 
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6.3.3.2 MT and NRA Timers 


The CP master interface also contains the "no response abort" (NRA) and master 
transaction (MT) timers. The NRA timer times out 2 ps (assuming 70 ns CP-bus 
cycle) after the NCA initiates an I/O transaction on the CP-bus. If the NRA timer 
times out before the NCA receives a response from an I/O device, the NCA aborts 
the transaction on the CP-bus (no response abort). The MT timer has 4 settings 

: 144, 1440, 14400, and 144000 cycles, which translate to 10.08 us, 100.8 us, 
1.008 ms, and 10.08 ms for 70 ns CP-bus cycle time. During an I/O transaction 
initiated by the CP master interface to the CP-bus, the timer times out if the 
master interface does not receive any response. 


The purpose of the MT and NRA timers is to prevent either of the CP-buses from 
becoming "hung" due to hardware or software errors. The NRA timer prevents a 
CP-bus from hanging due to a software error in which an access to a nonexistent 
I/O address is attempted. Each of the devices on the CP-bus with the exception of 
the SSC asserts a "not_me" signal during such accesses. When all the "not_me" 
signals on the CP-bus are asserted, external logic generates an NRA input to 
the NCA, to inform it that none of the devices on the corresponding CP-bus have 
claimed ownership of the issued address. Since the SSC does not implement a 
"not_me" signal, the NCA will wait 2 us to give the SSC a chance to respond to 
the transaction before the NRA timer expires. If the SSC does not complete the 
transaction within this time, then a no response abort takes place and the I/O 
transaction is terminated. 


The purpose of the MT timer is to prevent either of the CP-buses from becoming 
"hung" in the situation when a hardware error has occurred. In such cases, it is 
possible that one of the chips connected to the CP-bus in question could fail to 
assert its "not_me” signal, indicating that it intends to respond to the transaction. 
If the chip in question fails to respond to the transaction, presumably due to a 
hardware failure, the MT timer will expire, thus aborting the I/O transaction and 
preventing the associated CP-bus from becoming "hung." 


6.3.3.3 CP Slave Interface 


The CP slave interface responds to DMA transactions on the CP-bus. This 
subsection features three queues: 


¢ CP_WBUF - CP_WBUF is a 2-entry deep queue that holds the DMA write 
transaction information. Each entry contains one quadword address and two 
quadword data elements, together with a valid bit. The address element 
contains information for setting up the NVAX address cycle while the data 
element contains the write data and a BDATA bit, which is set if bad parity 
is found in the corresponding quadword of write data on the CP bus. The 
entry is validated when the DMA address and all the DMA write data have 
been loaded into CP_WBUF. When the contents of one or more entries is 
valid, a request is sent to the NDAL arbitration unit. The CP_WBUF entry is 
invalidated when the write transaction corresponding to this entry is initiated 
on the NDAL. 


¢ CP_MEMRD - On DMA reads, the slave interface places the read address 
in CP_MEMRD, a quadword address buffer that holds the information for 
setting up the NDAL address cycle. The valid bit for this buffer is set after 
ensuring that the DMA read address does not hit in CP_WBUF. If the DMA 
read address hits in CP_WBUF, the validation of the CP_MEMRD entry is 
held off until CP_WBUF is flushed. When the valid bit is set, a request is 
sent to the NDAL arbitration unit. 
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¢ CP_RBUF - This buffer holds the DMA memory read data that it receives 
from the NDAL slave interface. This is a hexword data buffer that is 
organized as longwords (that is, every longword contains a valid bit). The 
NCA prefetches (programmable) DMA memory read data up to an octaword. 
As the requested read data is returned to the DMA device on the CP-bus, the 
associated valid bit is cleared. 


As a CP-bus slave, the NCA accepts all transactions addressed in the memory 
space. The NCA will signal an error to the CP-bus master on DMA transactions 
addressed in VAX I/O space. 


6.3.4 Registers 


This section describes the NCA’s internal registers. The NCA has seven control 
and status registers (NCA_CSR) and three interval clock registers. These ten 
registers are longword-aligned. The NCA supports only I/O write to one register 
per transaction by the NVAX CPU. However, quadword read by the NVAX CPU 
of two NCA registers per transaction is allowed. 


All the registers are cleared on power-up reset, unless otherwise specified in the 
following description. Write operations to read-only registers do not cause any 
errors and are responded to as normal operations; however, the operations do not 
alter any of the register contents. 


The register block also contains a receive buffer and a transmit buffer. The 
receive buffer is used to store the register address in register read (and data, if 
register write). The transmit buffer is used to store the read data of a register 
read transaction while the register block is waiting to return the data to the 
NDAL. If the I/O address happens to be NCA’s CSR or interval timer address, 
the NCA’s CSR control logic sequences the read or write to the appropriate 
register. On reads, the read data together with the CMD and ID is placed in the 
transmit buffer and the valid bit is set in the transmit buffer. Once this occurs, 
the transmit buffer sends a request to the NDAL arbitration unit in the NDAL 
master interface. When the NCA is granted the mastership of the NDAL, the 
data, CMD, and ID are driven onto NDAL. On writes, the write data is written 
into the appropriate register. 
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Table 6—2 NCA CSR and Interval Timer Registers 


No. of 

Number Name Address Registers 
CESR Error status register 2102 0000 1 
CMCDSR Mode control and diagnostic register 2102 0004 1 
CSEAR1 CP1 slave error address register 2102 0008 1 
CSEAR2 CP2 slave error address register 2102 000C 1 
CIOEAR1 CP1 I/O error address register 2102 0010 1 
CIOEAR2 CP2 I/O error address register 2102 0014 1 
CNEAR NDAL error address register 2102 0018 1 
ICCS Interval clock control status register 2100 0060 1 
NICR Next interval count register 2100 0064 1 

ICR Interval count register 2100 0068 1 

1 NCA_ Interrupt acknowledge registers 2100 0100 - 4 
CSR7-10 010F 


These are virtual registers and they are read-only. 


6.3.4.1 Control and Status Registers 
The NCA has seven CSRs, the functions of which are decribed below. 


6.3.4.2 Error Status Register (CESR) 
The NCA reports error information in CESR. 
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Figure 6-2 Error Status Register 


L. CP1 NON-EXISTENT 10 ERROR 
CP1 10 ERROR 
_ CP1 10 READ PARITY ERROR 
CP1 BUS ERROR 
CP1 DMA PARITY ERROR 
wu. ©P1 10 LOST ERROR 
. CP1 DMA LOST ERROR 
CP1 MT TIMEOUT ERROR 
CP2 NON-EXISTENT 1O ERROR 
_... ©P2 10 ERROR 
_ CP2 10 READ PARITY ERROR 
cP2 BUS ERROR 
CP2 DMA PARITY ERROR 
_.. CP2 10 LOST ERROR 
. CP2 DMA LOST ERROR 
CP2 MT TIMEOUT ERROR 
CP1 PREL 
wen ©P2 PREL 
. NDAL PREL 


NDAL PARITY ERROR 
NDAL NO ACK ERROR 
wun NDAL CP1 TIMEOUT ERROR 
. NDAL CP2 TIMEOUT ERROR 
NDAL ILL_LENGTH 
NDAL RESERVED CMD 
uu. NDAL LOST ERROR 
. RDR NO ACK ERROR 


ERROR SUMMARY 


CESR : 2102 0000 


Table 6-3 Error Status Register, CESR 


Type, Reset 
Register Field Bit State Description 


Error Summary 31 RO, 0 This bit is "1" when any error is logged by the 
NCA in this register, with the exception of 
CESR<25>, which does not affect this bit. It 
is cleared when all the error bits are cleared. 


Unused 30:28 MBZ, 0 These bits are read as 0. 


RDR NO_ACK Error 27 WC, 0 This bit is set if NCA does not receive ACK_L 
when it is initiating an RDRx to the NDAL. No 
address is logged when this bit is set. 


NDAL Lost Error 26 WC, 0 This bit is set if an error condition described in 
CESR<23:21> occurs and CESR<21> is already 
set. When this bit is set, CNEAR contains the 
address of the previous error condition that has 
not been cleared at the time the current error 
condition happens. It is possible that this bit 
is set but all the error bits in CESR<23:21> 
are cleared because of the asynchronous events. 
When this happens, the CNEAR may contain an 
invalid address. 


RO—Read-only 
RW—Read/write 
WC—Write one-to-clear 
MBZ—Read-only, read as 0 


(continued on next page) 
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Register Field 


Bit 


Type, Reset 
State 


Description 


NDAL Reserved cmd 


NDAL IIl_length 


NDAL CP2 Timeout Error 


NDAL CP1 Timeout Error 


NDAL NO_ACK Error 


NDAL Parity Error 


Unused 
NDAL PREL 


CP2 PREL 


25 


24 


23 


22 


21 


20 


19 
18 


17 


WC, 0 


WC, 0 


WC, 0 


WC, 0 


WC, 0 


WC, 0 


MBZ, 0 
WC, 0 


WC, 0 


This bit is set when the NDAL interface detects 
a reserved command during any NDAL cycle and 
this bit is not already set. No address is logged 
when this bit is set. 


This bit is set when the NDAL interface detects 
an illegal length during an NDAL transaction 
addressed to the NCA and when this bit is not 
already set. No address is logged when this bit is 
set. 


This bit is set if not all requested read data 

is returned from the memory within the 
NDAL cycles specified by the NDAL timer 
prescaler (CMCDSR<11:10>) for the DMA read 
transactions initiated on the CP2-bus, and this 
bit is not already set. 


This bit is set if not all requested read data 

is returned from the memory within the 
NDAL cycles specified by the NDAL timer 
prescaler (CMCDSR<11:10>) for the DMA read 
transactions initiated on the CP1-bus, and this 
bit is not already set. 


This bit is set if no ACK_L is received during 
an NCA-initiated memory transaction and 
this bit is not already set. CNEAR contains 
the error address when this bit is set and 
CMCDSR<23:22> are not set. 


This bit is set if NCA detects an NDAL parity 
error on any NDAL cycles and this bit is not 
already set. No address is logged when this bit is 
set. 


This bit is read as 0. 


This bit is set when there is no XA (that is, 
CMCDSR<&> is set) present and there is no 
pending interrupts at both the CP1 and CP2 port 
at the priority level indicated by the interrupt 
vector read on the NDAL. No address is logged 
when this bit is set. 


This bit is set when an interrupt vector read is 
initiated on the CP2-bus and either CP2_ERR_L 
is asserted or CP2 master transaction (MT) timer 
times out. In either case, the NCA returns to the 
NDAL with RDR and NDAL bit<33,01> set to 1. 
No address is logged when this bit is set. 


RO—Read-only 
RW—Read/write 
WC—Write one-to-clear 
MBZ—Read-only, read as 0 


(continued on next page) 
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Table 6-3 (Cont.) Error Status Register, CESR 


Type, Reset 
Register Field Bit State Description 
CP1 PREL 16 WC, 0 This bit is set when an interrupt vector read is 


performed on the CP1-bus and either CP1_ERR_ 
L is asserted or CP1 master transaction (MT) 
timer times out. In either case, the NCA returns 
to the NDAL with RDR and NDAL bit<33,01> set 
to 1. No address is logged when this bit is set. 


CP2 MT Timeout Error 15 WC, 0 This bit is set if the I/O read or write transaction 
initiated by the NCA to the CP2-bus causes 
the CP2 master transaction (MT) timer to time 
out and this bit is not already set. CIOEAR2 
contains the I/O error address when this bit is set 
and CESR<10:8> are not set. 


CP2 DMA Lost Error 14 WC, 0 This bit is set if CESR<12> is already set and 
either a DMA device initiates an I/O transaction 
on the CP2-bus or the CP2 interface detects a 
parity error on a DMA write data. When this bit 
is set, CSEAR2 contains an address for a previous 
error that has not been cleared at the time the 
current error condition happens. It is possible 
that this bit is set but the error bit in CESR<12> 
is cleared because of the asynchronous events. 
When this happens, the CSEAR2 may contain an 
invalid address. 


CP2 IO Lost Error 13 WC, 0 This bit is set if any bit in CESR<15,10:8> 
is already set and any of the error conditions 
described in CESR<15,10:8> occurs. When this 
bit is set, CIOEAR2 contains an address for a 
previous error that has not been cleared at the 
time the current error condition happens. It is 
possible that this bit is set but all the error bits 
in CESR<15,10:8> are cleared because of the 
asynchronous events. When this happens, the 
CIOEAR2 may contain an invalid address. 


CP2 DMA Parity Error 12 WC, 0 This bit is set if the NCA detects a parity error 
in the DMA write data on the CP2-bus. CSEAR2 
contains the DMA write address when this bit is 
set. 


CP2 Bus Error 11 WC, 0 This bit is set if a DMA device on the CP2-bus 
initiates an I/O transaction or a transaction with 
one of the reserved commands. No address is 
logged when this bit is set. 


CP2 IO Read Parity Error 10 WC, 0 This bit is set if the NCA detects a parity error 
in the I/O read data on the CP2-bus. CIOEAR2 
contains the I/O error address when this bit is set 
and CESR<15,9:8> are not set. 


RO—Read-only 
RW—Read/write 
WC—Write one-to-clear 
MBZ—Read-only, read as 0 


(continued on next page) 
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Register Field Bit 


Type, Reset 
State 


Description 


CP2 IO Error 9 


CP2 Nonexistent IO Error 8 


CP1 MT Timeout Error 7 


CP1 DMA Lost Error 6 


CP1 IO Lost Error 5 


CP1 DMA Parity Error 4 


CP1 Bus Error 3 


WC, 0 


WC, 0 


WC, 0 


WC, 0 


WC, 0 


WC, 0 


WC, 0 


This bit is set if an NCA-initiated transaction, 
read or write, on the CP2-bus results in CP2_ 
ERR_L assertion. CIOEAR2 contains the 

I/O error address when this bit is set and 
CESR<15,10,8> are not set. 


This bit is set if CP2_NRA timer times out and 
CP2_NRA pin is asserted on an NCA-initiated I/O 
transaction on the CP2-bus. CIOEAR2 contains 
the I/O error address when this bit is set and 
CESR<15,10:9> are not set. 


This bit is set if the I/O read or write transaction 
initiated by the NCA to the CP1-bus causes the 
CP1 master transaction (MT) timer to times 

out and this bit is not already set. CIOEAR1 
contains the I/O error address when this bit is set 
and CESR<2:0> are not set. 


This bit is set if CESR<4> is already set and 
either a DMA device initiates an I/O transaction 
on the CP1-bus or the CP1 interface detects a 
parity error on a DMA write data. When this 
bit is set, CSEAR1 contains an address for a 
previous error that has not been cleared at the 
time the current error condition happens. It is 
possible that this bit is set but the error bit in 
CESR<4> is cleared because of the asynchronous 
events. When this happens, the CSEAR1 may 
contain an invalid address. 


This bit is set if any bit in CESR<7,2:0> is 
already set and any of the error conditions 
described in CESR<7,2:0> occurs. When this 
bit is set, CIOEAR1 contains an address for a 
previous error that has not been cleared at the 
time the current error condition happens. It 
is possible that this bit is set but all the error 
bits in CESR<7,2:0> are cleared because of the 
asynchronous events. When this happens, the 
CIOEAR1 may contain an invalid address. 


This bit is set if the NCA detects a parity error 
in the DMA write data on the CP1-bus. CSEAR1 
contains the DMA write address when this bit is 
set. 


This bit is set if a DMA device on the CP1-bus 
initiates an I/O transaction or a transaction with 
one of the reserved commands. No address is 
logged when this bit is set. 


RO—Read-only 
RW—Read/write 
WC—Write one-to-clear 
MBZ—Read-only, read as 0 


(continued on next page) 
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Table 6-3 (Cont.) Error Status Register, CESR 


Type, Reset 
Register Field Bit State Description 
CP1 10 Read Parity Error 2 WC, 0 This bit is set if the NCA detects a parity error 


in the I/O read data on the CP1-bus. CIOEAR1 
contains the I/O error address when this bit is set 
and CESR<’7,1:0> are not set. 


CP1 IO Error 1 WC, 0 This bit is set if an NCA-initiated transaction, 
read or write, on the CP1-bus results in CP1_ 
ERR_L assertion. CIOEAR1 contains the 
I/O error address when this bit is set and 
CESR<7,2,0> are not set. 


CP1 Nonexistent IO Error 0 WC, 0 This bit is set if CP1_NRA timer times out and 
CP1_NRA pin is asserted on an NCA-initiated I/O 
transaction on the CP1-bus. CIOEAR1 contains 
the I/O error address when this bit is set and 
CESR<7,2:1> are not set. 


RO—Read-only 
RW—Read/write 
WC—Write one-to-clear 
MBZ—Read-only, read as 0 


6.3.4.3 Mode Control and Diagnostic Register (CMCDSR) 


The NCA operating modes are controlled by information in this register. In 
addition, this register is used for storing diagnostic status information. The 
following is a description of all the bit fields in the register. 


Figure 6-3 Mode Control and Diagnostic Status Register 


L. FORCE CP1 BUS OWNER 
_ FORCE CP2 BUS OWNER 
FORCE WRITE BUFFER HIT 
ENABLE PREFETCH 
_.. FORCE WRONG NDAL SLAVE PARITY 
_ FORCE WRONG NDAL MASTER PARITY 
FORCE WRONG CP1 BUS PARITY 
FORCE WRONG CP2 BUS PARITY 
_.. 102 1D ENABLE 
_.-.. CQBIC MODE 
_. NDAL TIMER PRESCALER 
CP1 IVR TIMER PRESCALER 
CP2 IVR TIMER PRESCALER 
CP1 INTERRUPT 
_. CP2 INTERRUPT 


CMCDSR : 2102 0004 


6-14 KA680 I/O Subsystem 


KA680 I/O Subsystem 
6.3 NCA Chip Architecture 


Table 6-4 Mode Control and Diagnostic Status Register, CMCDSR 


Register Field 


Bit 


Type, Reset 
State 


Description 


Unused 
CP2 Pending Interrupt 


CP1 Pending Interrupt 


CP2 MT Timer 
Prescaler 


CP1 MT Timer 
Prescaler 


NDAL Timeout 
Prescaler 


CQBIC Mode 


IO2 ID Enable 


Force Wrong CP2 Bus 
Parity 


Force Wrong CP1 Bus 
Parity 


31:24 
23:20 


19:16 


15:14 


13:12 


11:10 


MBZ, 0 
RO, 0 


RO, 0 


RW, 11 


RW, 11 


RW, 0 


RW, 0 


RW, 0 


RW, 0 


RW, 0 


This field reads as 0. 


This 4-bit field shows the presence of interrupts at 
IPL 17, 16, 15, and 14, respectively, on the CP2-bus. 


This 4-bit field shows the presence of interrupts at 
IPL 17, 16, 15, and 14, respectively, on the CP1-bus. 


This 2-bit field is used as a prescaler to the CP2 
master transaction timer. The CP2 MT timer has 4 
settings: 00 (binary) = 144 cycles, 01 (binary) = 1440 
cycles, 10 (binary) = 14400 cycles, and 11 (binary) = 
144000 cycles. 


This 2-bit field is used as a prescaler to the CP1 
master transaction timer. The CP2 MT timer has 4 
settings: 00 (binary) = 144 cycles, 01 (binary) = 1440 
cycles, 10 (binary) = 14400 cycles, and 11 (binary) = 
144000 cycles. 


This 2-bit field is used as a prescaler for the NDAL 
transaction pending timers. These timers should 
always time out after the NMC pending timers time 
out. The NDAL timer prescaler has 4 settings: 00 
(binary) = 3200 cycles, 01 (binary) = 2000 cycles, 10 
(binary) = 1000 cycles, and 11 (binary) = 500 cycles. 


When set, this bit indicates that CQBIC (Q—-bus 
adapter) is present on the CP2-bus. 


When set, this bit enables the NCA to use IO2 

ID when initiating CP2 DMA transactions on the 
NDAL. This bit should be set if there is no XA in the 
NVAX system. 


When set to 1, this bit causes the CP2 port to 
generate wrong data parity on the incoming and 
outgoing data. The NCA clears this bit after it 
initiates or responds to one CP2-bus transaction. 
This bit is for test purposes only and should not be 
set during normal operation. 


When set to 1, this bit causes the CP1 port to 
generate wrong data parity on the incoming and 
outgoing data. The NCA clears this bit after it 
initiates or responds to one CP-bus transaction. This 
bit is for test purposes only and should not be set 
during normal operation. 


RO—Read-only 
RW—Read/write 


WO—Write-only, read as 0 
WC—Write one-to-clear 


MBZ—Read-only, read as 0 


(continued on next page) 
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Table 6—4 (Cont.) Mode Control and Diagnostic Status Register, CMCDSR 


Type, Reset 
Register Field Bit State 


Description 


Force Wrong NDAL 5 RW, 0 
Master Parity 


Force Wrong NDAL 4 RW, 0 
Slave Parity 


Enable Prefetch 3 RW, 0 


Force Write Buffer Hit 2 RW, 0 


Force CP2 Bus Owner 1 RW, 1 


Force CP1 Bus Owner 0 RW, 1 


When set to 1, this bit forces the NCA NDAL master 
parity generator to generate incorrect parity in the 
command field in the address cycle (or data cycle if 
read data return) of the next NCA-initiated NDAL 
transaction. This bit is self-cleared by the NCA after 
it has initiated one NDAL transaction. This bit is 
for test purposes only and should not be set during 
normal system operation. 


When set to 1, this bit forces the NDAL slave 
parity generator to generate incorrect parity on 
any NDAL cycle. This emulates parity errors in all 
PARITY_H<2:0>. The NCA asserts S_LERR_L and 
sets CESR<NDAL_PARITY_ERROR> every cycle 
as long as this bit is set. This bit is self-cleared by 
the NCA after it has responded to one valid NDAL 
transaction addressed to the NCA other than a read 
data return. This bit is for test purposes only and 
should not be set during normal system operation. 


When set to 1, this bit enables the CP1 and CP2 
ports to perform data prefetching on DMA read 
transactions. This is set to 1 during powerup when 
CP_RESET_L is asserted. 


When set to 1, this bit forces all DMA read addresses 
from CP1 and CP2 ports to hit any valid element 

in the CP1_WBUF and CP2_WBUF queues, 
respectively. This bit should be set for diagnostic 
purposes only. 


When set to 1, the NCA asserts CP2_DMR_L to 
become the CP2-bus master regardless of whether 
there is an I/O transaction pending in the NCA 
or not. This bit is set to 1 during powerup when 
CP_RESET_L is asserted, and must be cleared by 
software to allow normal I/O transactions to take 
place. 


When set to 1, the NCA asserts CP1_DMR_L to 
become the CP1-bus master regardless of whether 
there is an I/O transaction pending in the NCA 
or not. This bit is set to 1 during powerup when 
CP_RESET_L is asserted, and must be cleared by 
software to allow normal I/O transactions to take 
place. 


RO—Read-only 
RW—Read/write 
WO—Write-only, read as 0 
WC—Write one-to-clear 
MBZ—Read-only, read as 0 


6.3.4.4 CP1 Slave Error Address Register (CSEAR1) 
When either CESR<3> or CESR<4> is set because of a CP1-bus slave error 
condition, the corresponding octaword address is logged in this register. The 
content remains valid until both error bits are cleared. This register is read-only 
and contains valid information only when either of CESR<4:3> is set. 
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Figure 6-4 CP1 Slave Error Address Register 
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Table 6—5 CP1 Slave Error Address Register, CSEAR1 


Type, Reset 
Register Field Bit State Description 
Unused 31:30 MBZ, 0 These bits read as 0. 
Error Address 29:4 RO, 0 These bits contain the CP1 slave octaword address. 
Unused 3:0 MBZ, 0 These bits read as 0. 


RO—Read-only 
RW—Read/write 
WC—Write one-to-clear 
MBZ—Read-only, read as 0 


6.3.4.5 CP2 Slave Error Address Register (CSEAR2) 


When either CESR<10> or CESR<11> is set because of a CP2-bus slave error 
condition, the corresponding octaword address is logged in this register. The 
content remains valid until both error bits are cleared. This register is read-only 
and contains valid information only when either of CESR<11:10> is set. 


Figure 6-5 CP2 Slave Error Address Register 
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Table 6-6 CP2 Slave Error Address Register, CSEAR2 


Type, Reset 
Register Field Bit State Description 
Unused 31:30 MBZ, 0 These bits read as 0. 
Error Address 29:4 RO, 0 These bits contain the CP2 slave octaword address. 
Unused 3:0 MBZ, 0 These bits read as 0. 


RO—Read-only 
RW—Read/write 
WC—Write one-to-clear 
MBZ—Read-only, read as 0 


6.3.4.6 CP11O Error Address Register (CIOEAR1) 


When any of CESR<7, 2:0> is set because of an error condition in an NCA- 
initiated I/O transaction on the CP-bus, the corresponding address and ID are 
logged in this register. The content remains valid until all CESR<7, 2:0> bits are 
cleared. This register is read-only and contains valid information only when any 
of the error bits is set. 


Figure 6-6 CP1 IO Error Address Registers 
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Table 6-7 CP1 IO Error Address Register, CIOEAR1 


Type, Reset 
Register Field Bit State Description 
Commander ID 31:29 RO, 0 These bits contain the commander ID corresponding to 
the I/O transaction that resulted in the error condition. 
Error Address 28:0 RO, 0 These bits contain the address corresponding to the I/O 


transaction that resulted in the error condition. 


RO—Read-only 
RW—Read/write 
WC—Write one-to-clear 
MBZ—Read-only, read as 0 
MBO—Read-only, read as 1 
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6.3.4.7 CP2 10 Error Address Register (CIOEAR2) 


When any of CESR<7, 10:8> is set because of an error condition in an NCA- 
initiated I/O transaction on the CP2-bus, the corresponding address and ID are 
logged in this register. The content remains valid until all CESR<7, 10:8> bits 
are cleared. This register is read-only and contains valid information only when 
any of the error bits is set. 


Figure 6-7 CP2 10 Error Address Registers 
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Table 6-8 CP2 IO Error Address Register, CIOEAR2 


Type, Reset 
Register Field Bit State Description 
Commander ID 31:29 RO, 0 These bits contain the commander ID corresponding to 
the I/O transaction that resulted in the error condition. 
Error Address 28:0 RO, 0 These bits contain the address corresponding to the I/O 


transaction that resulted in the error condition. 


RO—Read-only 
RW—Read/write 
WC—Write one-to-clear 
MBZ—Read-only, read as 0 
MBO—Read-only, read as 1 


6.3.4.8 NDAL Error Address Register (CNEAR) 


When any of CESR<23:21> is set because of an error condition in an NCA- 
initiated NDAL transaction, the corresponding address and ID are logged in this 
register. The content remains valid until all CESR<23:21> bits are cleared. This 
register is read-only and contains valid information only when any of the error 
bits is set. 


Figure 6-8 NDAL Error Address Registers 
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Table 6-9 NDAL Error Address Register, CNEAR 


Type, Reset 

Register Field Bit State Description 

Commander ID 31:29 RO, 0 These bits contain the commander ID corresponding to 
NCA-initiated NDAL transaction that resulted in the 
error condition. 

Error Address 28:0 RO, 0 These bits contain the address corresponding to NCA- 
initiated NDAL transaction that resulted in the error 
condition. 


RO—Read-only 
RW—Read/write 
WC—Write one-to-clear 
MBZ—Read-only, read as 0 


6.4 Interval Clock Registers 


The interval clock is used for accounting, for time-dependent events, and to 
maintain the software date and time. The NVAX CPU implements the interrupt 
at IPL 22 programmed interval only (that is, the interval timer increments at 1 
ps intervals). The interval timer consists of three registers and a counter. For 
information on the interval clock, refer to the VAX Architecture Reference Manual. 


6.4.1 Interval Clock Control and Status Register (ICCS) 


The ICCS is a 32-bit register containing the control and status information for the 
interval timer. Figure 6—9 shows the format of the ICCS register, and Table 6-10 
lists the bit decriptions. 


Figure 6-9 Interval Clock Control and Status Register 
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Table 6-10 Interval Clock Control and Status Register, ICCS 


Type, Reset 

Register Field Bit State Description 

Error 31 RW, 0 This bit is set when ICR overflows and if interrupt is 
already set. This bit indicates an unacknowledgement 
from the CPU. This bit is write one-to-clear. 

Unused 30:8 RO, 0 These bits read as 0. 

Interrupt 7 RW, 0 This bit is set when the ICR ( Section 6.4.3) overflows. 
This bit is write one-to-clear. 

Interrupt Enable 6 RW, 0 When set, an interrupt request is generated every time 


interrupt is set. When clear, no interrupt is requested. 
Similarly, if interrupt is already set and interrupt 
enable is set, an interrupt request is generated. This bit 
is cleared on powerup. 


Single Step 5 RW, 0 When run is cleared, each time this bit is set, the ICR is 
incremented by 1. This bit should not be set when run 
is set, otherwise the consequence is unpredictable. This 
bit is cleared at powerup. 

Transfer 4 RW, 0 When set, the content of NICR ( Section 6.4.2) is 
transferred to ICR. This bit is write-only. This bit 
should not be set when run is set; otherwise, the 
consequence is unpredictable. 


Unused 3:1 RO, 0 These bits read as 0. 


Run 0 RW, 0 When set, ICR increments every 1 us. This bit is cleared 
on powerup. 


RO—Read-only 
RW—Read/write 
WC—Write one-to-clear 
MBZ—Read-only, read as 0 


6.4.2 Next Interval Count Register (NICR) 


The NICR is a 32-bit register holding the initial count value for the ICR register. 
When ICR overflows, the contents of NICR are loaded into ICR. This is a 
read/write register. This register is set to the value FFFFD8FO0 (hex) (10 ms) 
upon powerup. 


6.4.3 Interval Count Register (ICR) 


The ICR is a 32-bit register holding the current count of the interval timer. The 
content of ICR is incremented by 1 every 1 ps when ICCS<0> is set, or every time 
ICCS<5> is set. When ICR overflows or when ICCS<4> is set , the content of 
NICR is loaded into this register. This register is read-only. This register is set to 
the value FFFFD8F0 (hex) (10 ms) upon powerup. 


6.5 NCA Transaction Handling 


This section describes the NCA behavior by tracing the flow of transactions 
through the functional units of the chip. There are seven types of transactions 
supported by the NCA: 


e IO write 


e 10 read 
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6.5.1 


¢ Interrupt vector read 
¢ Register read 

e Register write 

¢ DMA read 

¢ DMA write 


10 Write 


IO write transactions are initiated by the NVAX CPU on the NDAL. IO write 
can be WRITE or WDISOWN operations to addresses assigned to the CP1 or 
CP2 ports (Table 6-1). WDISOWN is treated as WRITEs. The data length for 
IO writes is always quadword, but could be masked on longword alignment. 
A quadword write is performed as two longword writes on the CP-bus in two 
separate CP-bus grants. 


The address on the NDAL is latched and decoded by the NDAL slave interface 

to determine if the NVAX CPU is addressing the CP1 or CP2 ports. If it is an 
address to one of the ports, and there is no parity error, the NCA acknowledges 
the NDAL transaction and begins to process it. The address and the port ID are 
latched in the IO_RW queue. The data is latched from the NDAL during the data 
cycle that follows. Again, parity is calculated and checked. If there is no parity 
error on the data, then the data is latched in the IO_RW queue and the valid bit 
for the entry is set. If a parity error is detected, then a soft error interrupt will be 
requested, the transaction is ignored, and the valid bit of the entry of the IO_RW 
queue is not set. 


If the NDAL address is not within the NCA address space, it is ignored by the 
NCA. If it is within the NCA address space but a parity error is detected, or 

if the address is outside the NCA address space and a parity error is detected, 
then ACK_L is not asserted. Instead, a soft error interrupt is requested to notify 
the NVAX CPU of the error. In addition, the NDAL parity error bit is set in 
CMCDSR. 


If the IO write is for port 1 (port 2), then CP1_RBUF (CP2_RBUF) is invalidated. 
Depending on the byte masks of the IO write, the transaction will require either 
one or two longword writes on the associated CP-bus. The CP1_IORBUF (CP2_ 
IORBUF) is flushed before the IO write can proceed on CP1 (CP2) port; that is, 
any previous IO read must be forwarded to the NDAL interface before the IO 
write can proceed. After CP1_IORBUF (CP2_IORBUF) has been flushed, the 
NCA initiates the transaction on the CP1 (CP2) bus. 


The lower longword of the quadword is initiated first on the CP-bus, unless the 
byte masks corresponding to the lower longword are all 0s. Then if the byte 
masks corresponding to the upper longword are not all 0s, the IO write for the 
upper longword is initiated on the CP-bus. If the byte masks corresponding to the 
lower longword are all 0s, then the IO write for the upper longword is initiated 
on the CP-bus regardless of the value of the byte masks for the upper longword. 


6.5.2 IO Read 


IO read transactions are initiated by the NVAX CPU on the NDAL. IO reads can 
be caused by NDAL IREAD, DREAD, or OREAD operations to addresses assigned 
to the CP1 and CP2 ports (Table 6-1). As in IO writes, the data length is always 
a quadword, and may be masked. OREADs are treated as DREAD operations. 
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IO reads are handled the same way as IO writes on the NDAL slave interface, 
except that no data is latched in the IO_RW queue. If the address is within the 
NCA address space, then the valid bit for the entry is set. A quadword read is 
performed as two longword reads on the CP-bus in two separate CP bus grants. 


If the IO read is for port 1 (port 2), then CP1_RBUF (CP2_RBUF) is invalidated. 
Depending on the byte masks of the IO read, the transaction can either be one 
or two longword reads. The CP1_IORBUF (CP2_IORBUF) is flushed before 

the IO read can proceed on CP1 (CP2) port; that is, any previous IO read must 
be forwarded to the NDAL interface before the next IO read can proceed. When 
CP1_IORBUF (CP2_IORBUF) has been flushed, the NCA initiates the transaction 
on the CP1 (CP2) bus. An IREAD will result in an I-stream read, and an OREAD 
or DREAD will result in a D-stream read on the CP1 (CP2) bus. 


The lower longword of the quadword is initiated first on the CP-bus, unless the 
byte masks for this longword are all Os. In this case, the upper longword read 
happens first. If the byte masks for the lower longword are all Os, then the upper 
longword is initiated on the CP-bus regardless of the value of the upper longword 
byte masks. 


As the read data is returned on the CP1 (CP2) bus, it is stored in the CP1_ 
IORBUF (CP2_IORBUF) queue in the CP1 (CP2) port. When all the read data 
has been returned, a request is sent to the NCA’s arbitration unit of the NDAL 
master interface. 


The NCA NDAL master interface arbitrates with the other NDAL devices for 
mastership of the NDAL. When NDAL bus ownership has been granted, the 
NCA initiates a read data return cycle (RDR) and drives the data from the CP1_ 
IORBUF (CP2_IORBUF) onto the NDAL to complete the read. 


The RDR number is determined by the NDAL address of the IO read. Table 6-11 
shows how the RDR number is calculated. 
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Table 6-11 IO Read RDR number 


NDAL<4:3> RDR Number Comments 

00 (binary) RDRO Quadword 0 of a hexaword 
01 (binary) RDR1 Quadword 1 of a hexaword 
10 (binary) RDR2 Quadword 2 of a hexaword 
11 (binary) RDR3 Quadword 3 of a hexaword 


6.5.3 Interrupt Vector Read 


An interrupt vector read appears on the NDAL as a DREAD, IREAD, or OREAD 
to one of four longwords within the range E100 0100 to E100 010F (hex). The 
address must be longword-aligned. Interrupt vector reads are initiated by the 
NVAX CPU in response to an assertion of one of the NVAX CPU’s interrupt 
lines (IRQ<3:0>). The read address identifies the level of the interrupt being 
serviced. The read data length is always a quadword, which is masked to a single 
longword. The NCA expects the NVAX CPU to provide the proper byte mask 
information; that is, the byte mask should either be 03 (hex) or 30 (hex). 


IRQ<3:0>can be asserted only by the NCA, which asserts these signals on behalf 
of devices on either of the two CP-buses. 


The interrupt vector read cycle starts in the NCA when the NDAL slave interface 
detects a read address cycle on the NDAL. The address is latched and decoded to 
determine if it is an interrupt vector address. If it is an interrupt vector address, 
and there is no parity error, the NCA acknowledges the NDAL transaction. The 
address is then latched in the IO_RW queue. 


The address decoder determines the destination of the read. If one of the CP 
ports has an interrupt of the proper level pending, then the read is directed to 
that port. If both ports have interrupts pending at that level, then the CP2 port 
will receive the interrupt vector read. If neither port has an interrupt, then the 
NCA will abort the vector read transaction. 


If the interrupt vector read is directed to either of the two CP ports, the ID of 
that port is latched in the IO_RW queue together with the address, and the valid 
bit of the entry is set. 


If the IO read is for port 1 (port 2), then CP1_RBUF (CP2_RBUF) is invalidated. 
The CP1_IORBUF (CP2_IORBUF) is also flushed before the read can proceed on 
CP1 (CP2) port. This is done because any previous IO read must be forwarded 
to the NDAL interface before the interrupt vector read can proceed. When CP1_ 
IORBUF (CP2_IORBUF) is flushed, the NCA initiates the transaction on the CP1 
(CP2) bus. 


As the read data is returned on the CP1 (CP2) bus, it is stored in the CPx_ 
IORBUF queue in the CP1 (CP2) port. A request is sent to the arbitration unit of 
the NDAL master interface. 


The NCA NDAL master interface arbitrates for the NDAL mastership after the 
request is received. When NDAL bus ownership is granted, the NCA initiates a 
read data return (RDR) cycle and drives the data from the CP1_IORBUF (CP2_ 
IORBUF) onto the NDAL to complete the read. 


The RDR number for interrupt vector read is determined in Table 6-12. 
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Table 6-12 Interrupt Vector Read RDR Number 


NDAL<31:0> RDR Number 
2100 0000 (IPL 14) RDRO 
2100 0100 (IPL 15) RDRO 
2100 1000 (IPL 16) RDR1 
2100 1100 (IPL 17) RDR1 
NOTE 


If the NCA initiates an I/O transaction (IO reads, IO writes, or interrupt 
vector reads) and the CP master transaction timer times out, the NCA 
will terminate the transaction. No error will be logged. 


6.5.4 Register Read 


Register read can be a read to NCA’s CSR registers or to the VAX standard 
interval timer registers. Register read transactions are initiated by the 
NVAX CPU on the NDAL. They appear as DREAD, IREAD, or OREAD 
operations, and the data length is always a quadword (1 data transfer). 


The read transaction starts in the NCA when the NDAL slave interface detects 
a read address cycle on the NDAL. The address is latched on the NCA, and a 
decoder determines if it is the NCA’s register address. If there is a match, and 
there is no parity error, the NCA acknowledges the NDAL cycle. 


The NCA address decoder determines that the destination of the read is the 
register block. The address is then latched in the receive buffer. The NCA always 
returns the register data corresponding to the quadword address regardless of 
the byte mask value. The quadword data is stored in the transmit buffer. When 
the read data is ready, a request is forwarded to the arbitration unit of the NCA’s 
NDAL master interface. 


The NCA then arbitrates with the other NDAL devices for control of the NDAL. 
When it becomes bus master, it initiates a read data return cycle and drives the 
data onto the NDAL to complete the read. 


6.5.5 Register Write 


Register write transactions are initiated by the NVAX CPU on the NDAL. They 
appear as either WRITE or WDISOWN operations and the write data length is 
always a quadword, but only one longword data is written in the appropriate 
register at a time. 


The register write transaction starts in the NCA when the NDAL slave interface 
detects a write address cycle on the NDAL. The address is latched by the NCA, 
and a decoder determines if it is the NCA’s register address. If there is a match, 
and there is no parity error, the NCA acknowledges the NDAL transaction. 


The NCA address decoder determines if the destination of the write is the 
register block. The address and the write data are then latched in the receive 
buffer. The address indicates the quadword boundary while the mask field of the 
lower longword selects the proper longword. If the mask field is not all 0s, then 
the write data on NDAL<31:0> is written into the NCA register on the lower 
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longword address. If the mask field is all 0s, then the data on NDAL<63:32> is 
written into the NCA register on the upper longword address. 


6.5.6 CP1 DMA Read 


6-26 


CP1 DMA reads are initiated by I/O devices that reside on the CP1-bus. DMA 
reads are supported by the NCA to memory address space only. All DMA reads to 
VAX I/O address space are terminated by the NCA by asserting the CP1_ERR_L 
signal on the CP1-bus. DMA reads can be longword (2 words), quadword (4 
words), hexword (6 words), or octaword (8 words) on the CP1-bus. 


When the NCA’s prefetch enable bit is set, the NCA will respond to DMA ready 
cycles to main memory by prefetching sequential locations in anticipation of 
future requests to these memory locations by DMA devices. Table 6-13 shows the 
prefetch scheme the NCA uses. 


Table 6-13 CP1 DMA Memory Read Prefetching 


CP1 Read Data Length Data Length Requested 
Longword Quadword 
Quadword Octaword 
Hexword Octaword 
Octaword Hexaword 


When a DMA read happens on the CP1-bus, the address is latched in the CP1_ 
MEMRD buffer. The NCA compares the address with the previous DMA read 
address. If they are within the same hexaword boundary, then the current 
requested read data might be in the CP1_RBUF. The NCA then checks if all the 
requested longwords are in the CP1_RBUF. If this is also true, then the NCA 
will not forward the DMA read request to the NDAL master interface. Instead, 
the CP1 slave interface returns the read data onto the CP1-bus directly from the 
CP1_RBUF. As each longword is driven onto the CP1-bus, the valid bit of the 
corresponding longword is cleared. 


If the DMA read address is not within the same hexaword boundary of the 
previous DMA read, or if not all the requested read data is in the CP1_RBUF, 
then the CP1 slave interface will forward the read request to the NDAL master 
interface and all entries in the CP1_RBUF will be invalidated. 


It is possible for the NCA to receive a new DMA read transaction on the CP1-bus 
before all the prefetch data of the previous DMA read has been received. If the 
current DMA read is within the same hexaword as the previous read but not all 
the requested longword data is in the CP1_RBUF, then the CP1 slave interface 
will wait until all the prefetch is completed. Once all the prefetched data has 
returned, the read data will return from the CP1_RBUF, thus avoiding the need 
to forward the DMA read request to the NDAL. If the current hexaword DMA 
read address does not match the previous one, the DMA read request will be 
forwarded to the NDAL master interface, since the data in CP1_RBUF is for a 
different hexaword address. 


It is possible that a DMA read address matches a DMA write transaction waiting 
in the CP1_WBUF. If the addresses are within the same hexaword boundary, 
then the DMA read request is stalled until the DMA write has completed on the 
NDAL. 
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If the DMA read is a lock operation, then any outstanding DMA writes waiting 
in CP1_WBUF are flushed before the read request is sent to the NDAL master 
interface. 


The NCA gives higher priority to DMA reads than writes if both are pending in 
the CP1 slave interface so that the DMA read operations will not hold up the 
CP1-bus (DMA writes are dump-and-run). 


When the NDAL master interface receives a DMA request from the CP1 slave 
interface, the NCA arbitrates for the NDAL on behalf of the CP1-bus. When 
NDAL mastership is granted to the NCA for this transaction, the DMA read 
address is forwarded to the NDAL interface and driven onto the NDAL. Some 
time later, data is returned from the memory. Each quadword of data is latched 
in the NDAL interface and in CP1_RBUF. According to NDAL protocol, the first 
quadword returned on the NDAL is guaranteed to be the requested quadword. 


As the data becomes available in CP1_RBUF, it is driven onto the CP1-bus. As 
each longword of data is returned on the CP1-bus, the corresponding entry is 
invalidated in CP1_RBUF. When all the requested data has been returned, the 
transaction completes on the CP1-bus. The NCA is now ready to receive new 
DMA transactions on the CP1-bus. The nonrequested data is kept in CP1_RBUF 
as prefetch data. 


The prefetch data in the CP1_RBUF is invalidated under the following conditions: 
¢ DMA memory write or write-unlock on the CP1-bus to any memory address 


¢ DMA memory read with different hexaword address or the prefetch data does 
not contain all the requested longword data 


¢ DMA memory read-lock on the CP1-bus to any memory address 
e I/O transaction on the CP1-bus initiated by the NCA 


6.5.7 CP1 DMA Write 


CP1 DMA writes are initiated by I/O devices that reside on the CP1-bus. DMA 
writes are supported by the NCA only to VAX memory space; that is, NOT to VAX 
I/O space. All DMA writes to VAX I/O space are terminated by the NCA with 
the assertion of the CP1-bus signal CP1_ERR_L. DMA write can be longword, 
quadword, hexword, or octaword on the CP1-bus. Longword and quadword writes 
are performed as quadword writes on the NDAL, and hexword and octaword 
writes are performed as octaword writes on the NDAL. Writes can be masked or 
unmasked. 


When a DMA write happens on the CP1-bus, the address and data are latched 
in the CP1_WBUF. A DMA write on the CP1-bus causes the CP1_RBUF to be 
invalidated. When the address and write data are ready, the NCA will arbitrate 
for the NDAL on behalf of the CP1-bus. Once the NDAL has been granted to the 
NCA, the write is initiated on the NDAL and the transaction completes. 


6.5.8 CP2 DMA Read 


CP2 DMA reads are initiated by I/O devices that reside on the CP2-bus. DMA 
reads are supported by the NCA to VAX memory space only. All DMA reads to 
VAX I/O space are terminated by the NCA by asserting the CP2-bus signal CP2_ 
ERR_L. The NCA supports DMA reads originating on the CP2-bus of longword, 
quadword, hexword, or octaword length. 
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When NCA prefetching is enabled, the NCA will prefetch read data by requesting 
more data from the system main memory than originally requested on the 
CP2-bus. Table 6-14 shows the prefetch scheme the NCA uses. 


Table 6-14 CP2 DMA Memory Read Prefetching 


CP2 Read Data Length Data Length Requested on NDAL 
Longword Quadword 
Quadword Octaword 
Hexword Octaword 
Octaword Hexaword 


When a DMA read happens on the CP2-bus, the address is latched in the CP2_ 
MEMRD buffer. The NCA compares the address with the previous DMA read 
address. If they are within the same hexaword boundary, then the current 
requested read data might be in the CP2_RBUF. The NCA then checks whether 
all the requested longwords are in the CP2_RBUF. If this is also true, then the 
NCA will not forward the DMA read request to the NDAL master interface. 
Instead, the CP2 slave interface returns the read data onto the CP2-bus directly 
from the CP2_RBUF. As each longword is driven onto the CP2-bus, the valid bit 
of the corresponding longword is cleared. 


If the DMA read address is not within the same hexaword boundary of the 
previous DMA read or not all the requested read data is in the CP2_RBUF, then 
the CP2 slave interface forwards the read request to the NDAL master interface, 
and all entries in the CP2_RBUF are invalidated. 


It is possible for the NCA to receive a new DMA read transaction on the CP2-bus 
when not all the prefetch data of the previous DMA read has been received. If 
the current DMA read is within the same hexaword as the previous read but 
not all the requested longword data is in the CP2_RBUF, then the CP2 slave 
interface will wait until all the prefetch is completed. Once all the prefetched 
data has returned, the read data will return from the CP2_RBUF, thus avoiding 
the need to forward the DMA read request to the NDAL. If the current hexaword 
DMA read address does not match the previous one, the DMA read request will 
be forwarded to the NDAL master interface, since the data in CP2_RBUF is for a 
different hexaword address. 


It is possible that a DMA read address matches a DMA write transaction waiting 
in the CP2_WBUF. If the addresses are within the same hexaword boundary, 
then the DMA read request is stalled until the DMA write has completed on the 
NDAL. 


If the DMA read is a lock operation, then any outstanding DMA writes waiting 
in CP2_WBUF are flushed before the read request is sent to the NDAL master 
interface. 


The NCA gives higher priority to DMA reads than writes if both are pending in 
the CP2 slave interface so that the DMA read operations will not hold up the 
CP2-bus (DMA writes are dump-and-run). 


The CQBIC is the only DMA device on the CP2-bus. Therefore, when a DMA 
longword read occurs on the CP2-bus as the transaction is forwarded to the 
NDAL, the NCA asserts the QBUS_TRANS_L signal to the NDAL arbiter in the 
NMC. The assertion of this signal causes a modification of the NDAL arbitration 
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priority such that the CP2-bus (CQBIC) has the highest priority on the NDAL. 
This is done to reduce the latency on memory reads by Q22-bus devices. 


Once asserted, the NCA will continue to assert QBUS_TRANS_L for TBD cycles 
after the read data is returned from the NMC on the NDAL, or until any of the 
following conditions happen on the CP2-bus: 


1. The longword memory read is followed by a memory write. 
2. The longword memory read is followed by a longword memory read. 
3. The longword memory read is followed by a quadword memory read. 


In case 1, QBUS_TRANS_L is deasserted after the memory write completes on 
the CP2-bus. In case 2, QBUS_TRANS_L is kept asserted for another TBD cycle 
after the read data for the second longword memory read is returned from the 
NMC. In case 3, QBUS_TRANS_L is deasserted when the quadword memory read 
address and command are pushed onto the NDAL. 


When the NDAL master interface receives a DMA request from the CP2 slave 
interface, a bus request is asserted on the NDAL. When the bus grant is received, 
the DMA read address is forwarded to the NDAL interface and driven onto the 
NDAL. Later, data is returned from the memory. Each quadword of data is 
latched in the NDAL interface and then CP2_RBUF. According to NDAL protocol, 
the first quadword returned on the NDAL is guaranteed to be the requested 
quadword. 


As the data becomes available in CP2_RBUF, it is driven onto the CP2-bus. As 
each requested longword is driven onto the CP2-bus, the corresponding CP2_ 
RBUF entry is invalidated. When all the requested data has been returned, the 
transaction completes on the CP2-bus. The NCA is now ready to receive new 
DMA transactions on the CP2-bus. The nonrequested data is kept in CP2_RBUF 
as prefetch data. 


The prefetch data in the CP2_RBUF is invalidated under the following conditions: 
¢ DMA memory write or write-unlock on the CP2-bus to any memory address 


¢ DMA memory read with different hexaword address or the prefetch data does 
not contain all the requested longword data 


¢ DMA memory read-lock on the CP2-bus to any memory address 
¢ I/O transaction on the CP2-bus initiated by the NCA 


6.5.9 CP2 DMA Write 


CP2 DMA writes are initiated by I/O devices that reside on the CP2-bus. DMA 
writes are supported by the NCA to VAX memory space only. All DMA writes to 
VAX I/O space are terminated by the NCA by asserting the CP2-bus CP2_ERR_L 
signal. The NCA supports DMA writes on the CP2-bus of longword, quadword, 
hexword, or octaword length. Longword and quadword writes are performed as 
quadword writes on the NDAL, and hexword and octaword writes are performed 
as octaword writes on the NDAL. Writes can be masked or unmasked. 


When a DMA write happens on the CP2-bus, the address and data are latched 
in the CP2_WBUF. A DMA write on the CP2-bus causes the CP2_RBUF to be 
invalidated. When the address and all write data have been latched by the NCA, 
a DMA write request is sent to the NCA’s NDAL master interface. The NCA 
will then arbitrate for the NDAL on behalf of the CP2-bus DMA device (CQBIC). 
When the NDAL is granted to the NCA, the write is initiated on the NDAL, 
thereby completing the DMA write transaction. 
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Errors in the NCA can be of two types - NDAL-related errors and CP-bus related 
errors. These errors are described in the following tables. 


Table 6-15 NDAL-Related Errors and NCA Responses 


Description of Error 


Specific Situation 


Action Taken by NCA 


NCA detects a parity 


error on any NDAL cycle 


ACK _L is not received 
when NCA is master 


NCA detects illegal 
length to NCA 
addressing space 


NCA detects reserved 


command on any NDAL 


cycle 


Read data return error 


Interrupt vector read 
error 


Error in CMD<3:0> 
or ID<2:0> 


Address cycle, error 
on NDAL<63:0> 


Data cycle, error on 
NDAL<63:0> 


Address cycle 


Data cycle 


Address cycle 


Address or data cycle 


NDAL CP timer 
times out before all 
data is returned 


Receive RDE 


No interrupts 
pending at that 
level and XA is not 
present 


No ACK_L; set CESR<NDAL_PARITY_ERROR>; 
asserts S_ERR_L. 


No ACK_L; set CESR<NDAL_PARITY_ERROR>; 
asserts S_ERR_L. 


No ACK_L; set CESR<NDAL_PARITY_ERROR>; 
asserts S_ERR_L. If DMA read, then NDAL CP timer 
will eventually time out and CP-bus interface assert 
CP_ERR_L if not all requested data is received. 


Assert H_ERR_L if DMA write; set CESR<NACK>. 
Log address in CNEAR. If DMA read, then asserts 
CP_ERR_L to abort. 


If DMA write, then asserts H_ERR_L; set 
CESR<NACK>. Log address in CNEAR. If read 
data return, then asserts S_ERR_L; set CESR<RDR_ 
NACK>. 


Asserts S_ERR_L; no ACK_L; set CESR<ILL_ 
LENGTH>; no address log. 


No ACK_L; set CESR<RESERVE_CMD>; no address 
log. 


Set CESR<CP_TIMEOUT_ERROR>; log address in 
CNEAR. If CP-bus is still waiting for data, assert CP_ 
ERR_L to abort. 


If data is requested on CP-bus, assert CP_ERR_L; 
otherwise, ignore data returned. 


Set CESR<NCA_PREL>; return with RDR and NDAL 
bit<33,1> set to 1. 
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Table 6-16 CP-Bus (CP1 and CP2 Buses) Related Errors and NCA Responses 


Description of Error 


Specific Situation 


Action Taken by NCA 


NCA detects a parity 
error on CP-bus 


Invalid DMA address 
Reserved command 


CP_ERR_L is asserted 
when NCA is master 


No response abort 


CP MT timer times out 


DMA write data 
cycle 


IO read data cycle 
Interrupt vector read 


data cycle 


NCA receives IO 
space address 


NCA receives 
reserved command 
IO read 

IO write 

Interrupt vector read 
IO read 


IO write 


Interrupt vector read 


Interrupt vector read 


IO read 


IO write 


Set CESR<CP_DMA_PAR_ERR>; log address in 
CSEAR1 or CSEAR2. Perform BADWDATA operation 
on NDAL; asserts S_ERR_L. 


Set CESR<CP_IO_READ_PAR_ERRs>; return RDE on 
NDAL. Log address in CIOEAR1 or CIOEAR2. 


Set CESR<CP_IO_READ_PAR_ERR3>, return RDE on 
NDAL. Log address in CIOEAR1 or CIOEAR2. 
Asserts CP_ERR_L; set CESR<CP_BUS_ERR>; no 
address logging. 

Asserts CP_ERR_L; set CESR<CP_BUS_ERR>; no 
address logging. 

Set CESR<CP_IO_ERR>; return RDE to NDAL. Log 
address in CIOEAR1 or CIOEAR2. 

Assert H_ERR_L; set CESR<CP_IO_ERR>. Log 
address in CIOEAR1 or CIOEAR2. 


Set CESR<CP_PREL>; return RDR with NDAL 
bit<33,1> set to 1. 


Set CESR<CP_NXIO>; return RDE on NDAL. Log 
address in CIOEAR1 or CIOEAR2. 


Assert H_ERR_L; set CESR<CP_NXIO>. Log address 
CIOEAR1 or CIOEAR2. 


No action; the NCA will continue to wait for the read 
data or until either the CP MT timer times out or 
the assertion of CP_ERR_L before terminating the 
transaction. 


Terminates CP-bus transaction by deasserting CP_AS_ 
L and CP_DS_L. Return RDR with NDAL bit<33,1> set 
to 1; set CESR<CP_PREL>. 


Terminates CP-bus transaction by deasserting CP_AS_ 
L and CP_DS_L. Set CESR<CP_MT_TIMEOUTS; log 
address in CIOEAR1 or CIOEAR2. 


Asserts H_ERR_L; terminates CP bus transaction by 
deasserting CP_AS_L and CP_DS_L. Set CESR<CP_ 
MT_TIMEOUTS>; log address in CIOEAR1 or CIOEAR2. 
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The Console Line, TOY Clock 


7.1 KA680 Console Serial Line 


The console serial line provides the KA680 processor with a full-duplex, RS-423 
EIA, serial line interface, which is also RS-232-C compatible. The only data 
format supported is 8-bit data with no parity and one stop bit. The four internal 
processor registers (IPRs) that control the operation of the console serial line 
are a superset of the VAX console serial line registers described in the VAX 
Architecture Reference Manual. 


7.1.1 Console Registers 


There are four registers associated with the console serial line unit. They 
are implemented in the SSC chip and are accessed as IPRs 32-35. Refer to 
Table 7-1. 


Table 7-1 Console Registers 


IPR Number Register Name Mnemonic 
Dec Hex 
32 20 Console Receiver Control/Status RXCS 
33 21 Console Receiver Data Buffer RXDB 
34 22 Console Transmit Control/Status TXCS 
35 23 Console Transmit Data Buffer TXDB 


7.1.1.1. Console Receiver Control/Status Register (IPR 32) 


The console receiver control/status register (RXCS), internal processor register 
32, is used to control and report the status of incoming data on the console serial 
line. The format is shown in Figure 7-1. Table 7—2 lists the bit descriptions. 
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Figure 7-1 Console Receiver Control/Status Register (IPR 3249 204.) 


31 30 29 28 27 26 25 24 23 22 21 20 1918 17 16 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00 


RX |E 


RX DONE 
LJ-01300-T10 


Table 7-2 Console Receiver Control/Status Register 


Data Bit 


Name 


Description 


<31:8> 


<7> 


<6> 


<5:0> 


MBZ 


RX DONE 


RX IE 


Unused 


These bits read as zeros; writes 
have no effect. 


Receiver done. Read-only. Writes 
have no effect. This bit is set 
when an entire character has been 
received and is ready to be read 
from the RXDB register. This bit 
is automatically cleared when the 
RXDB register is read. It is also 
cleared on powerup and on the 
negation of DCOK. 


Receiver interrupt enable. 
Read/write. When set, this bit 
causes an interrupt to be requested 
at IPL14 with an SCB offset of F8 
if RX DONE is set. When cleared, 
interrupts from the console receiver 
are disabled. This bit is cleared on 
powerup and on the negation of 
DCOK. 


These bits read as zeros. Writes 
have no effect. 


7.1.1.2 Console Receiver Data Buffer (IPR 33) 


The console receiver data buffer (RXDB), internal processor register 33, is used to 
buffer incoming data on the serial line and capture error information. The format 
is shown in Figure 7—2. Bit descriptions are listed in Table 7-3. 
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Figure 7-2 Console Receiver Data Buffer (IPR 3349 2146) 


16 15 14 13 12 11 10 08 07 


RCV BRK Received Data Bits 
MBZ 
FRM ERR 
OVR ERR 
ERR 
LJ-01301-TIO 
Table 7-3 Console Receiver Data Buffer 
Data Bit Name Description 
<31:16> MBZ These bits always read as zero. 
Writes have no effect. 
<15> ERR Error. Read-only. Writes have no 


effect. This bit is set if RBUF <14> 
or <13> is set. It is clear if these 
two bits are clear. This bit cannot 
generate a program interrupt. 
Cleared on powerup and on the 
negation of DCOK. 


<14> OVR ERR Overrun error. Read-only. Writes 
have no effect. This bit is set if a 
previously received character was 
not read before being overwritten 
by the present character. Cleared 
by reading the RXDB, on powerup, 
and on the negation of DCOK. 


<13> FRM ERR Framing error. Read-only. Writes 
have no effect. This bit is set 
if the present character did not 
have a valid stop bit. Cleared by 
reading the RXDB, on powerup, 
and on the negation of DCOK. 
Error conditions are updated 
when the character is received. 
Error conditions remain 
present until the character 
is read, at which point the 
error bits are cleared. 


<12> MBZ This bit always reads as zero. 
Writes have no effect. 


(continued on next page) 
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Table 7-3 (Cont.) Console Receiver Data Buffer 


Data Bit Name Description 


<1l> RCV BRK Received break. Read-only. Writes 
have no effect. This bit is set at 
the end of a received character 
for which the serial data input 
remained in the space condition for 
20 bit times. Cleared by reading 
the RXDB, on powerup, and on the 
negation of DCOK. 


<10:8> MBZ These bits always read as zero. 
Writes have no effect. 


<7:0> Received Data Bits Read-only. Writes have no effect. 
These bits contain the last received 
character. 


7.1.1.3 Console Transmitter Control/Status Register (IPR 34) 


The console transmitter control/status register (TXCS), internal processor register 
34, is used to control and report the status of outgoing data on the console serial 
line. The format is shown in Figure 7—3. Bit descriptions are listed in Table 7-4. 


Figure 7-3 Console Transmitter Control/Status Register (IPR 3449 2246) 


08 07 06 05 03 02 01 00 


XMIT BRK 


MBZ 


MAINT 


TX IE 


TX RDY 
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Table 7-4 Console Transmitter Control/Status Register 


Data Bit 


Name 


Description 


<31:8> 


<7> 


<6> 


<5:3> 


<2> 


<l> 


<0> 


MBZ 


TX RDY 


TX IE 


MBZ 


MAINT 


Unused 


XMIT BRK 


These bits read as zeros. Writes 
have no effect. 


Transmitter ready. Read-only. 
Writes have no effect. This bit 

is cleared when TXDB is loaded, 
and set when TXDB can receive 
another character. This bit is set 
on powerup and on the negation of 
DCOK. 


Transmitter interrupt enable. 
Read/write. When set, this bit 
causes an interrupt to be requested 
at IPL14 with an SCB offset of FC 
if TX RDY is set. When cleared, 
interrupts from the console receiver 
are disabled. This bit is cleared on 
powerup and on the negation of 
DCOK. 


These bits read as zeros. Writes 
have no effect. 


Maintenance. Read/write. This bit 
is used to facilitate a maintenance 
self-test. When MAINT is set, 

the external serial output is set 

to MARK and the serial output is 
used as the serial input. This bit 
is cleared on powerup and on the 
negation of DCOK. 


This bit reads as zero. Writes have 
no effect. 


Transmit break. Read/write. When 
this bit is set, the serial output 

is forced to the space condition 
after the character in TXDB<7:0> 
is sent. While XMIT BRK is 

set, the transmitter will operate 
normally, but the output line will 
remain low. Thus, software can 
transmit dummy characters to time 
the break. This bit is cleared on 
powerup. 


7.1.1.4 Console Transmitter Data Buffer (IPR 35) 


The console transmitter data buffer (TXDB), internal processor register 35, 
is used to buffer outgoing data on the serial line. The format is shown in 


Figure 7-4. Table 7-5 lists the bit descriptions. 
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Figure 7-4 Console Transmitter Data Buffer (IPR 3549 2346) 


31 08 07 00 
Transmitted 
MBE Data Bits 
LJ-01303-TI0 


Table 7-5 Console Transmitter Data Buffer 


Data Bit Name Description 
<31:8> MBZ Read as 0. Writes have no effect. 
<7:0> Transmitted Data Bits Write-only. These bits are used 


to load the character to be 
transmitted on the console serial 
line. 


7.1.2 Break Response 


The console serial line unit recognizes a break condition, which consists of 20 
consecutively received space bits. If the console detects a valid break condition, 
the RCV BRK bit is set in the RXDB register. If the break was the result of 

20 consecutively received space bits, the FRM ERR bit is also set. If halts 

are enabled, the KA680 will halt and transfer program control to the console 
firmware ROM location E004 0000;g when the RCV BRK bit is set. RCV BRK 
is cleared by reading RXDB. Another mark followed by 20 consecutive space bits 
must be received to set RCV BRK again. 


7.1.3 Baud Rate 


The receive and transmit baud rates are always identical and are controlled by 
the SSC configuration register bits <14:12>. 


The user selects the desired baud rate through the baud rate select signals, which 
are received from an external 8-position switch mounted on the console module 
(H3604). The KA680 firmware must read this code from boot and diagnostic 
register bits <6:4>, compliment and then load it into SSC configuration register 
bits <14:12>. 


Table 7-6 shows the baud rate selection, the corresponding code as read in the 
boot and diagnostic register bits <6:4>, and the inverted code that should be 
loaded into SSC configuration register bits <14:12>. 


Table 7-6 Baud Rate Selection 


Baud Rate BDR<6:4> SSC<14:12> 
300 111 000 
600 110 001 


(continued on next page) 
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Table 7-6 (Cont.) Baud Rate Selection 


Baud Rate BDR<6:4> SSC<14:12> 
1200 101 010 
2400 100 011 
4800 011 100 
9600 010 101 
19200 001 110 
38400 000 111 


7.1.4 Console Interrupt Specifications 


Both the console serial line receiver and transmitter generate interrupts at IPL 
14. The receiver interrupts with a vector of F8;g, while the transmitter interrupts 
with a vector of FC jg. 


7.2 KA680 TOY Clock and Timers 


The KA680 clocks include time-of-year clock (TODR), a subset interval clock 
(subset ICCS), as defined in the VAX Architecture Reference Manual, and two 
additional programmable timers modeled after the VAX standard interval clock. 


7.2.1 Time-of-Year Clock (TODR) - EPR 27 


The time-of-year clock (TODR) forms an unsigned 32-bit binary counter that 
is driven from a 100 Hz oscillator, so that the least significant bit of the 
clock represents a resolution of 10 milliseconds, with less than .0025% error. 
The register counts only when it contains a nonzero value. This register is 
implemented in the SSC chip. The format is shown in Figure 7-5. 


Figure 7-5 Time-of-Year Clock (TODR) - (EPR 2749 1By46) 


31 00 
Number 10ms Intervals Since Setting 
LJ-01304-TIO 


The time-of-year clock is maintained during power failure by battery backup 
circuitry that interfaces, via the external connector, to a set of batteries mounted 
on the CPU console module. The TODR will remain valid for more than 162 
hours when using the NiCad battery pack (3 batteries in series) mounted on the 
I/O distribution insert panel. 


The SSC configuration register contains a battery low (BLO) bit which, if set after 
initialization, the TODR is cleared, and will remain at zero until software writes 
a nonzero value into it. 
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Note 


After writing a nonzero value into the TODR, software should clear the 
BLO bit by writing a one to it. 


7.2.2 Programmable Timers 


The KA680 features two programmable timers. Although they are modeled after 
the VAX standard interval clock, they are accessed as I/O space registers (rather 
than as internal processor registers) and a control bit has been added that stops 
the timer upon overflow. If so enabled, the timers will interrupt at IPL 14 upon 
overflow. The interrupt vectors are programmable and are set to 78 and 7C by the 
firmware. The KA680 firmware uses these timers. They are not preserved 
across console activity. 


Each timer is composed of four registers: 


Timer n control register 

Timer n interval register 

Timer n next interval register 
Timer n interrupt vector register 


The timer number (0 or 1) is represented by n. 


7.2.2.1. Timer Control Registers (TCRO and TCR1) 
The KA680 has two timer control registers: one for controlling timer 0 (TCRO), 
and one for controlling timer 1 (TCR1). TCRO is accessible at address 2014 
01001g, and TCR1 is accessible at 2014 01101. These registers are implemented 
in the SSC chip. Figure 7-6 shows the format. Table 7—7 lists the bit 
descriptions. 


Figure 7-6 Timer Control Registers (TCRO and TCR1) 


31 30 08 07 06 05 04 03 02 01 00 


LJ-01305-T10 
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Table 7-7 Timer Control Register Bit Descriptions 


Date Bit Name 


Description 


<31> ERR 


<30:8> MBZ 
<7> INT 


<6> IE 


<5> SGL 


<4> XFR 


<3> MBZ 
<2> STP 


<l> MBZ 
<0> RUN 


Error. Read/write to clear. This bit is set whenever 
the timer interval register overflows and the INT bit 
is already set. Thus, the ERR bit indicates a missed 
overflow. Writing a one to this bit clears it. Cleared on 
powerup. 


Read as zeros, must be written as zeros. 


Read/write to clear. This bit is set whenever the timer 
interval register overflows. If IE is set when INT is set, 
an interrupt is posted at IPL 14. Writing a one to this 
bit clears it. Cleared on powerup. 


Read/write. When this bit is set, the timer will interrupt 
at IPL 14 when the INT bit is set. Cleared on powerup. 


Read/write. Setting this bit causes the timer interval 
register to be incremented by one if the RUN bit is 
cleared. If the RUN bit is set, then writes to the SGL bit 
are ignored. This bit is always read as zero. Cleared on 
powerup. 


Read/write. Setting this bit causes the timer next 
interval register to be copied into the timer interval 
register. This bit is always read as zero. Cleared on 
powerup. 


Read as zeros, must be written as zeros. 


Read/write. This bit determines whether the timer stops 
after an overflow when the RUN bit is set. If the STP 
bit is set at overflow, the RUN bit is cleared by the 
hardware at overflow and counting stops. Cleared on 
powerup. 


Read as zeros, must be written as zeros. 


Read/write. When set, the timer interval register is 
incremented once every microsecond. The INT bit is 
set when the timer overflows. If the STP bit is set at 
overflow, the RUN bit is cleared by the hardware at 
overflow and counting stops. When the RUN bit is 
clear, the timer interval register is not incremented 
automatically. Cleared on powerup. 


7.2.2.2 Timer Interval Registers (TIRO and TIR1) 


The KA680 has two timer interval registers: one for timer 0 (TIRO), and one for 
timer 1 (TIR1). TIRO is accessible at address 2014 0104 1g, and TIR1 is accessible 


at 2014 011446. 


The timer interval register is a read-only register containing the interval count. 
When the RUN bit is 0, writing a 1 increments the register. When the RUN 
bit is 1, the register is incremented once every microsecond. When the counter 
overflows, the INT bit is set, and an interrupt is posted at IPL14 if the IE bit 
is set. Then, if the RUN and STP bits are both set, the RUN bit is cleared and 
counting stops. Otherwise, the counter is reloaded. The maximum delay that 
can be specified is approximately 1.2 hours. This register is cleared on powerup. 


Figure 7—7 shows the format. 
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Figure 7-7 Timer Interval Registers (TIRO and TIR1) 


31 00 
Timer Interval Register 


LJ-01306-TI0 


7.2.2.3 Timer Next Interval Registers (TNIRO and TNIR1) 
The KA680 has two timer next interval registers: one for timer zero (TNIRO), 
and one for timer one (TNIR1). TNIRO is accessible at address 2014 0108 ,, and 
TNIR1 is accessible at 2014 0118;¢. These registers are implemented in the SSC 
chip. The format is shown in Figure 7-8. 


This read/write register contains the value written into the timer interval register 
after overflow, or in response to a one written to the XFR bit. This register is 
cleared on powerup. 


Figure 7-8 Timer Next Interval Registers (TNIRO and TNIR1) 


31 00 
Timer Next Interval Register 


LJ-01307-TI0 


7.2.2.4 Timer Interrupt Vector Registers (TIVRO and TIVR1) 
The KA680 has two timer interrupt vector registers: one for timer zero (TIVRO), 
and one for timer one (TIVR1). TIVRO is accessible at address 2014 010Cy¢, and 
TIVR1 is accessible at 2014 011C jg. These registers are implemented in the SSC 
chip and are set to 781g and 7C 6, respectively, by the resident firmware. The 
format is shown in Figure 7-9. 


This read/write register contains the timer’s interrupt vector. Bits <31:10> and 
<1:0> are read as zeros and must be written as zeros. When TCRn<6> (IE) and 
TCRn<7> (INT) transition to one, an interrupt is posted at IPL14. When a timer’s 
interrupt is acknowledged, the content of the interrupt vector register is passed 
to the CPU, and the INT bit is cleared. Interrupt requests can also be cleared by 
clearing either the IE or INT bit. This register is cleared on powerup. 


7-10 The Console Line, TOY Clock 


The Console Line, TOY Clock 
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Figure 7-9 Timer Interrupt Vector Registers (TIVRO and TIVR1) 


31 10 09 02 01 00 
MBZ Interrupt Vector MBZ 
LJ-01308-T10 

Note 


Note that both timers interrupt at the same IPL (IPL14) as the console 
serial line unit. When multiple interrupts are pending, the console serial 
line has priority over the timers, and timer 0 has priority over timer 1. 
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KA680 Boot and Diagnostic Facility 


The KA680 boot and diagnostic facility features two registers, 512 KB of flash 
programmable read-only memory (FEPROM), and 1 KB of battery backed up 
RAM. The EPROM and battery backed up RAM may be accessed with longword, 
word, or byte references. 


8.1 Boot and Diagnostic Register (BDR) 


The boot and diagnostic register is a longword-wide register located in the VAX 
I/O page at physical addresses 2008 4000 - 2008 407C 1g. It can be accessed by 
KA680 software, but not by external Q22—bus devices. The BDR allows the boot 
and diagnostic firmware as well as the operating system to read various KA680 
configuration bits. 


The low byte and upper word of the BDR present the same information in each of 
the 32 successive longwords. The second byte (bits <15:8>) provides a byte of the 
LAN station address in each successive longword. Note that only the first eight 
bytes contain the station address. The next 24 bytes are provided for testing 
purposes. Figure 8—1 shows the format for the boot and diagnostic register. 
Table 8—1 describes the bits in the register. 


Figure 8-1 Boot and Diagnostic Register (BDR) 


31 30 29 27 26 24 23 19 18 16 15 08 07 06 04 03 02 01 00 


aE DSSI1 RESERVED DSSsl2 STATION_ADDRESS fel Hee 


RESERVED 
CABLE_OK 


ETHER_BOOT 


BDR_CD 
RESERVED 
MAN_TEST_MODE 
BRS_CD 


HLT_ENB 
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Table 8-1 Boot and Diagnostic Register Bit Description 


Data Bit Name Description 


<31> ETHER_BOOT Enable Ethernet remote boot. This bit reflects the 
current setting of the enable Ethernet remote boot 
jumper found on the console module (H3604). 


If this bit is zero, remote Ethernet boots are 
enabled. If this bit is one, remote Ethernet boots 
requests are ignored. 


<30> CABLE_OK Console module cable OK. When this bit is zero, 
there is a high probability that the console module 
cable is functioning correctly. 


If this bit is one, the console module cable is either 
malfunctioning or plugged in the wrong orientation. 
This bit is determined by sending a signal out to the 
console module over one path and reading it back 
down another on the cable. 


<29:27> Reserved Reserved. 


<26:24> DSSI1 This field contains the DSSI node number for the 
external DSSI bus (the bus that is accessed through 
the console module). 


<23:19> Reserved Reserved. 


<18:16> DSSI2 This field contains the DSSI node number for the 
internal DSSI bus (the bus that is accessed through 
the backplane connector). 


<15:8> STATION_ADDRESS The KA680’s hardware LAN station address 
EPROM is accessed by reading the BDR several 
times at successive addresses. The encoding for the 
station address is as follows: 


BDR + 00: SA byte 0 

BDR + 04: SA byte 1 

BDR + 08: SA byte 2 

BDR + 0C: SA byte 3 

BDR + 10: SA byte 4 

BDR + 14: SA byte 5 

BDR + 18: Checksum byte 0 

BDR + 1C: Checksum byte 1 

The last 24 bytes are provided for testing purposes. 


(continued on next page) 


8-2 KA680 Boot and Diagnostic Facility 


KA680 Boot and Diagnostic Facility 
8.1 Boot and Diagnostic Register (BDR) 


Table 8-1 (Cont.) Boot and Diagnostic Register Bit Description 


Data Bit Name Description 

<7> HLT ENB Halt enable, read-only. Writes have no effect. This 
bit reflects the state of break enable switch on the 
console module (H3604). The assertion of this signal 
enables the halting of the CPU upon detection of a 
console break condition. 
On a powerup, the KA680 resident firmware reads 
the HLT ENB bit to decide whether to enter the 
console emulation program (HLT ENB set) or to 
boot the operating system (HLT ENB clear). 
On the execution of of a HALT instruction while 
in kernel mode, the resident firmware reads the 
HLT ENB bit to decide whether to enter the console 
emulation program (HLT ENB set) or to restart the 
operating system (HLT ENB clear). 

<6:4> BRS CD Baud rate select—read-only. Writes have no effect. 
These three bits originate from the console module 
(H3604) baud rate select switch. They reflect 
the setting of the the baud rate as shown in the 
following table: 
BDR<6:4> Baud Rate 
111 300 
110 600 
101 1200 
100 2400 
011 4800 
010 9600 
001 19200 
000 38400 

<3> MAN_TEST_MODE Manufacturing test mode. Read-only. Writes have 
no effect. When this bit is set, the KA680 is in 
normal run mode. 
When cleared (by grounding a test point on the 
backplane), the KA680 is in manufacturing test 
mode. In this mode, special diagnostic test scripts 
can be run on the console. 

<2> RESERVED Reserved. 

<1:0> BDG_CD Boot and diagnostic code—read-only. Writes have 


no effect. This 2-bit field reflects the setting of 
the power-up mode switch on the console module 
(H3604). 


The KA680 firmware programs use BDG_CD <1:0> 
to determine the power-up mode as shown in the 
following table: 


(continued on next page) 
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Table 8-1 (Cont.) Boot and Diagnostic Register Bit Description 


Data Bit Name Description 
BDR<1:0> Power-Up Mode 
11 Run 
10 Language inquiry 
01 Test 
00 Unused 


8.2 Diagnostic LED Register (DLEDR) 


The diagnostic LED register (DLEDR), address 2014 003046, is implemented in 
the SSC chip and contains four read/write bits that control the external LED 
display. A zero in a bit lights the corresponding LED; all four bits are cleared 
on powerup and on the negation of DCOK to provide a power-up lamp test. 
Figure 8-2 shows the register format. Table 8—2 lists the bit descriptions. 


Figure 8-2 Diagnostic LED Register (DLEDR) 


31 04 03 00 


MBZ DSPL 


LJ-01310-TI0 


Table 8-2 Diagnostic LED Register Bit Descriptions 


Data Bit Name Description 
<31:4> MBZ Read as zeros, must be written as zeros. 
<3:0> DSPL Display. Read/write. These four bits update an external LED 


display. Writing a zero to a bit lights the corresponding LED. 
Writing a one to a bit turns its LED off. The display bits are 
cleared (all LEDs are lit) on powerup and on the negation of 
DCOK. 
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8.3 EPROM Memory 


The KA680 has 512 KB of flash EPROM memory for storing code for the following 
functions: 


Board initialization 

Board self-tests 

Boot code 

VAX standard console emulation 


EPROM memory may be accessed via byte, word, and longword references. The 
EPROM is organized as a 512K x 8-bit array. CP-bus parity is neither checked 
nor generated on EPROM references. 


Note 


The EPROM size must be set in the SSC configuration register before 
attempting to reference outside the first 8 KB block of the local EPROM 
space (E004 0000 - E004 1FFF4,). 


8.3.1 EPROM Address Space 


Only the first 256 KB of the 512 KB of ROM can be read in the region E004 
0000 - E007 FFFFj.. By appropriate programming of the SSC’s programmable 
address strobe 0 match and mask registers, all 512 KB of ROM can be read at the 
locations programmed by the user. Care must be taken, however, to ensure that 
the I/O address space chosen for the EPROM’s alternate address space is allowed 
by the NCA’s address map, and does not conflict with any other I/O devices on 
the module. When this is done, the lower 256 KB of the ROM’s alternate address 
space is a copy of the 256 KB that appears at E004 0000 - E007 FFFF. 


Note 


There is no concept of halt unprotect space (as used on previous Q22- 
based MicroVAX systems) on the KA680. 


Any I-stream read from the EPROM space places the KA680 in halt mode. 
The Q22—-bus SRUN signal is deasserted, causing the front panel RUN light to 
extinguish and the CPU is protected from further halts. 


Writes and D-stream reads to any address space have no effect on run mode/halt 
mode status. 


Note 


The logic that controls halt mode/run mode can only detect I-stream 
references to addresses mapped to CP2. 
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8.3.2 KA680 Resident Firmware Operation 


The KA680 CPU module’s 512 KB of EPROM contain the resident firmware, 
which can be entered by transferring program control to location E004 0000jg. 


Appendix C lists the various halt conditions that cause the KA680 to transfer 
program control to location E004 00004.. 


When running, the resident firmware provides the services expected of a VAX—11 
console system. In particular, the following services are available: 


¢ Automatic restart or bootstrap following processor halts or initial powerup. 


e An interactive command language allowing the user to examine and alter the 
state of the processor. 


¢ Diagnostic tests executed on powerup that check out the CPU, the memory 
system, the Q22—bus map, the SHAC, and the SGEC. 


¢ Support of video or hardcopy terminals as the console terminal. 


8.3.2.1 Power-Up Modes 


The boot and diagnostic EPROM programs use boot and diagnostic code <1:0> to 
determine the power-up modes shown in Table 8—3. 


Table 8-3 Power-Up Modes 
Code Power-up Mode 


11 Run (factory setting). If the console terminal supports the multinational 
character set (MCS), the user will be prompted for language if the time-of- 
year clock battery backup has failed, or SSC RAM is corrupted or uninitialized 
(1st powerup). Full startup diagnostics are run. 


01 Language inquiry. If the console terminal supports MCS, the user will be 
prompted for language on every powerup and restart. Full startup diagnostics 
are run. 

10 Test. EPROM programs run wraparound serial line unit (SLU) tests. 

00 Unused. 


8.4 Battery Backed-up RAM 


The KA680 contains 1 KB of battery backed-up static RAM, located in the SSC, 
for use as a console "scratchpad." This RAM supports byte, word, and longword 
references. Read operations take 700 ns to complete, while write operations 
require 600 ns. The RAM is organized as a 256 X 32-bit (one longword) array. 
The array appears in a 1 KB block of the VAX I/O page at addresses 2014 0400 - 
2014 O7FF1.. This array is not protected by parity, and CP-bus parity is neither 
checked nor generated on reads or writes to this RAM. 


8.5 KA680 Initialization 


The VAX architecture defines three kinds of hardware initialization: 
¢ Power-up initialization 
e I/O bus initialization 


¢ Processor initialization 
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8.5.1 Power-up Initialization 


Power-up initialization is the result of the restoration of power and includes a 
hardware reset, a processor initialization, and I/O bus initialization, as well as 
the initialization of several registers defined in the VAX Architecture Reference 
Manual. 


8.5.2 Hardware Reset 


A hardware reset occurs on powerup or the negation of DCOK. A hardware reset 
causes the hardware halt procedure to be initiated with a halt code of 03. It 
also initializes some IPRs and most I/O page registers to a known state. Those 
IPRs affected by a hardware reset are noted in Section 3.1.3. The effect that a 
hardware reset has on I/O space registers is documented in the description of the 
register. 


8.5.3 I/O Bus Initialization 


An I/O bus initialization occurs on powerup, the negation of DCOK, or as the 
result of an MTPR to IPR 55 (IORESET) or console UNJAM command. An I/O 
bus initialization clears the IPCR and DSER, and causes the Q22-bus interface 
to acquire both the CP-bus and Q22-bus, then assert the Q22-bus BINIT signal. 
The assertion of BINIT on the Q22-bus has no effect on the KA680. 


8.5.3.1 I/O Bus Reset Register (IPR 55) 


The I/O bus reset register (IORESET), IPR 5519, is implemented in the SSC chip. 
An MTPR of any value to IORESET causes an I/O bus initialization. Note that 
the SGEC and SHACs are not reset by MTPRs to IPR 55. 


8.5.4 Processor Initialization 


A processor initialization occurs on powerup, the negation of DCOK, as the result 
of a console INITIALIZE command, and after a halt caused by an error condition. 


In addition to initializing those registers defined in the VAX Architecture 
Reference Manual, the KA680 firmware must also configure main memory, 
the local I/O page, and the Q22-bus map during a processor initialization. 


8.5.4.1 Configuring the Local I/O Page 


The following registers control the configuration of the KA680 local I/O page. 
They are unique to CPU designs that use the SSC and they must be configured 
by the firmware during a processor initialization: 


e SSC base address register 
¢ BDR address decode match register 
¢ BDR address decode mask register 
e SSC configuration register 


¢ CP bus timeout register 
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8.5.5 SSC Base Address Register (SSCBR) 


The SSC base address register, address 2014 000016, controls the base addresses 
of a 2 KB block of the local I/O space, which includes the following: 


¢ The battery backed-up RAM 

¢ The registers for the programmable timers 

¢ The BDR address decode match and mask registers 
¢ The diagnostic LED register 


¢ A set of diagnostic registers that allow several external processor registers to 
be accessed via I/O page addresses 


This read/write register is set to 2014 0000;g on powerup and on the negation 
of DCOK. Bits SSCBR<31:30,10:0> are unused. They read as zeros, and must 
be written as zeros. SSCBR<29> is read as one and must be written as one. 
This register should also be set to 2014 000016 by firmware during processor 
initialization. The SSCBR has the format shown in Figure 8-3. 


Figure 8-3 SSC Base Address Register (SSCBR) 


31 30 29 28 11 10 00 


Base Address Bits <28:11> MBZ 


LJ-01457-T10 


8.5.6 BDR Address Decode Match Register (BDMTR) 


The BDR address decode match register, address 2014 014046, controls the 
base address of the BDR. This read/write register is cleared on powerup and 
on the negation of DCOK. BDMTR<31:30,1:0> are unused. They read as zeros, 
and must be written as zeros. This register should be set to 2008 400016 by 
firmware during processor initialization. The BDMTR has the format shown in 
Figure 8-4. 


Figure 8-4 BDR Address Decode Match Register (BDMTR) 


31 30 29 02 01 00 
MBZ Base Address Match Bits<29:2> MBZ 
LJ-01312-TIO 


8-8 KA680 Boot and Diagnostic Facility 


KA680 Boot and Diagnostic Facility 
8.5 KA680 Initialization 


8.5.7 BDR Address Decode Mask Register (BDMKR) 


The BDR address decode mask register, address 2014 01444, controls the range 
of addresses to which the BDR responds. (An example is the number of copies 
of the BDR that appear in the physical address space.) This read/write register 
is cleared on powerup and on the negation of DCOK. Bits BDMKR<31:30,1:0> 
are unused. They read as zeros, and must be written as zeros. This register 
should should be set to 0000 007C 16 (32 copies of the BDR) by firmware during 
processor initialization, because successive bytes of the KA680’s LAN station 
address ROM are read using the BDR. The BDMKR has the format shown in 
Figure 8-5. 


Figure 8-5 BDR Address Decode Mask Register (BDMKR) 


31 30 29 


02 01 00 


MBZ Base Address Mask Bits<29:2> MBZ 


LJ-01313-T10 


8.5.8 SSC Configuration Register (SSCCR) 


The SSC configuration register, address 2014 001046, controls the set-up 
parameters for the console serial line, programmable timers, EPROM, TOY 
clock, and BDR. The format is shown in Figure 8-6. Table 8—4 contains a list of 
the bit descriptions. 


Figure 8-6 SSC Configuration Register (SSCCR) 


31 30 


BLO 


28 27 26 25 24 23 22 20 19 18 16 15 14 12 11 07 06 04 03 02 


BDR EN 


CT BAUD SEL 


HALT PROT SPACE 


EPROM SIZE SEL 


IPL LVL SEL 
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Table 8-4 SSC Configuration Register Bit Descriptions 


Data Bit 


Name 


Description 


<31> 


<30:28> 
<27> 


<26> 
<25:24> 


<23> 


<22:20> 


<18:16> 


BLO 


MBZ 
IVD 


MBZ 


IPL_LVL_ 
SEL 


RSP 


ROM_ 
SIZE_SEL 


HALT 
PROT 
SPACE 


Battery low. Read/write. If the battery voltage goes below threshold while 
the module is powered down, this bit is set on powerup, after the assertion of 
DCOK after the assertion of POK. 


Once set, this bit can only be cleared by software writing it as one. If this bit 
is set, then the TOY clock will be cleared by powerup and and by the negation 
of DCOK. 


Read as zeros, must be written as zeros. 


Interrupt vector disable. Read/write. When set, the console serial line 
and programmable timers will not respond to interrupt acknowledge 
cycles. Cleared on powerup, by the negation of DCOK, and by a processor 
initialization. 

Read as zeros, must be written as zeros. 


IPL level select read/write. These bits are used to specify the IPL level of 
interrupt acknowledge cycle to which the console serial line and programmable 
timers respond. 


These bits must be cleared [programmed to 00 (binary)] for the console serial 
line and programmable timers to respond to interrupt acknowledge cycles that 
they generated (IPL 14). These bits are cleared on powerup, by the negation of 
DCOK, and by a processor initialization. 


ROM speed. Read/write. This bit is used to select the EPROM access time. 
This bit must be set for the KA680 EPROMs to run at maximum speed. This 
bit is cleared on powerup and by the negation of DCOK. It must be set to one 
by a processor initialization. 


EPROM address space size select. Read/write. These bits control the size of 
the range of addresses to which the EPROM responds. 


These bits must be set to 101 (binary) because the KA680 contains 256 KB 
of EPROM, yielding an address range of 256 KB (E004 0000 - E007 FFFF4.). 
These bits are cleared on powerup and by the negation of DCOK, yielding an 
address range of 8 KB (E004 0000 - E004 1FFF4¢). 


These bits must be set to the proper value during processor initialization. 


EPROM halt protect address space size select. Read/write. These bits control 
the size of the halt mode address range. 


These bits must be set to 101 (binary) because the KA680 contains 256 KB 
of EPROM, yielding a halt mode address range of 256 KB (E004 0000 - E007 
FFFF 6). These bits are cleared on powerup and by the negation of DCOK, 
yielding a halt mode address range of 8 KB (E004 0000 - E004 1FFFig ). 


These bits must be set to the proper value by a processor initialization. Note 
that any instruction fetch from the EPROM puts the KA680 in halt protect 
mode. 


(continued on next page) 
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Table 8—4 (Cont.) SSC Configuration Register Bit Descriptions 


Data Bit Name Description 

<15> CTP Control P enable. Read/write. When this bit is set, a CTRL/P typed at the 
console causes the CPU to be halted, if halts are enabled (BDR<7> set). When 
this bit is cleared, a BREAK typed at the console causes the CPU to be halted, 
if halts are enabled (BDR<7> set). This bit is cleared on powerup and by the 
negation of DCOK. 

<14:12> CT BAUD Console terminal baud rate select. Read/write. These bits are used to select 

SELECT the baud rate of the console terminal serial line. 

They are cleared on powerup and by the negation of DCOK. They should be 
loaded from compliment of BDR<6:4> by the processor initialization code. The 
bit encodings correspond to selected baud rates as shown in the following table: 
SSCCR<14:12> Baud Rate 
000 300 
001 600 
010 1200 
O11 2400 
100 4800 
101 9600 
110 19200 
111 38400 

<11:7> MBZ Read as zero, must be written as zero. 

<6:4> BDR EN Read/write. These bits are used to enable the BDR. They are cleared on 
powerup and by the negation of DCOK. These bits must be set to 111 (binary) 
by a processor initialization to enable the BDR. 

<3> MBZ Read as zero, must be written as zero. 

<2:0> MBZ Read as zero, must be written as zero. 
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KA680 Q22-bus Interface 


The KA680 includes a Q22-bus interface implemented via a single VLSI chip called the CQBIC. 
It contains a CP CP-bus to Q22-bus interface that supports the following: 


A programmable mapping function (scatter-gather map) for translating 22-bit, 
Q22-bus addresses into 29-bit CP addresses that allows any page in the 
Q22-bus memory space to be mapped to any page in main memory. 


A direct mapping function for translating 29-bit CP addresses in the local 
Q22-bus address space and local Q22-bus I/O page into 22-bit, Q22—bus 
addresses. 


Masked and unmasked longword reads and writes from the CPU to the 
Q22-bus memory and I/O space, and the Q22-bus interface registers. 
Longword reads and writes of the local Q22—bus memory space are buffered 
and translated into 2-word, block mode transfers on the Q22-bus. Longword 
reads and writes of the local Q22—bus I/O space are buffered and translated 
into two, single-word transfers on the Q22-bus. 


Up to 16-word, block mode writes from the Q22—bus to main memory. These 
words are buffered then transferred to main memory using two asynchronous 
DMA octaword transfers. For block mode writes of fewer than sixteen words, 
the words are buffered and transferred to main memory using the most 
efficient combination of octaword, quadword, and longword asynchronous 
DMA transfers. The maximum write bandwidth for block mode references 

is 3.3 MB/s. Block mode reads of main memory from the Q22-bus cause the 
Q22-bus interface to perform an asynchronous DMA quadword read of main 
memory and buffer all four words. Therefore, on block mode reads, the next 
three words of the block mode read can be delivered without any additional 
CP cycles. The maximum read bandwidth for Q22-bus block mode references 
is 2.4 MB/s. Q22-bus burst mode DMA transfers result in single-word reads 
and writes of main memory. 


Transfers from the CPU to the local Q22—-bus memory space, that result in 
the Q22-bus map translating the address back into main memory (local-miss, 
global-hit transactions). 


The Q22-bus interface contains several registers for Q22—bus control and 
configuration, interprocessor communication, and error reporting. 


The interface also contains Q22-bus interrupt arbitration logic that recognizes 
Q22-bus interrupt requests BR7-BR4, and translates them into CPU interrupts 
at levels 17-14. 


The Q22-bus interface detects Q22—bus "no sack" timeouts, Q22—bus interrupt 
acknowledge timeouts, Q22—bus nonexistent memory timeouts, and main memory 
errors on DMA accesses from the Q22—bus and Q22-bus device parity errors. 
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9.1 Q22-bus to Main Memory Address Translation 


On DMA references to main memory, the 22-bit, Q22—bus address must be 
translated into a 29-bit main memory address (Figure 9-1). This translation 
process is performed by the Q22-bus interface using the Q22—bus map. This 
map contains 8192 mapping registers, (one for each page in the Q22—bus memory 
space), each of which can map a page (512 bytes) of the Q22—bus memory 
address space into any of the 1024K pages in main memory. Since local I/O space 
addresses cannot be mapped to Q22—bus pages, the local I/O page is inaccessible 
to devices on the Q22-bus. Figure 9-1 shows how Q22-bus addresses are 
translated into main memory addresses. 


Figure 9-1 Q22-bus Address Translation 
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At powerup, the Q22—bus map registers, including the valid bits, are undefined. 
External access to main memory is disabled so long as the interprocessor 
communication register LM EAE bit is cleared. The Q22-bus interface monitors 
each Q22-bus cycle and responds if the following three conditions are met: 


1. The interprocessor communication register LM EAE bit is set. 
2. The valid bit of the selected mapping register is set. 


3. During read operations, the mapping register must map into existent main 
memory, or a Q22—bus timeout occurs. (During write operations, the Q22-bus 
interface returns Q22—bus BRPLY before checking for existent local memory; 
the response depends only on conditions 1 and 2 above). 
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Note 


In the case of local-miss, global-hit, the state of the LM EAE bit is 
ignored. 


If the map cache does not contain the needed Q22—bus map register, then the 
Q22-bus interface will perform an asynchronous DMA read of the Q22—bus map 
register before proceeding with the Q22—bus bus DMA transfer. 


9.1.1 Q22-—bus Map Registers (QMRs) 


The Q22-bus map contains 8192 registers that control the mapping of Q22—bus 
addresses into main memory. Each register maps a page of the Q22—bus memory 
space into a page of main memory. These registers are implemented in a 32 KB 
block of main memory, but are accessed through the CQBIC chip via a block of 
addresses in the I/O page. 


The local I/O space address of each register was chosen so that register address 
bits <14:2> are identical to Q22—bus address bits <21:9> of the Q22—bus page 
that the register maps. Table 9-1 lists the register addresses. 
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Table 9-1 Q22-—bus Map Register Addresses 


Register Address 


Q22-bus Addresses Mapped 


Hexadecimal 


Octal 


2008 8000 
2008 8004 
2008 8008 
2008 800C 
2008 8010 
2008 8014 
2008 8018 
2008 801C 


2008 FFFO 
2008 FFF4 
2008 FFF8 
2008 FFFC 


00 0000-00 01FF 
00 0200-00 03FF 
00 0400-00 05FF 
00 0600-00 O7FF 
00 0800-00 09FF 
00 0A00-00 OBFF 
00 0C00-00 ODFF 
00 0E00-00 OF FF 


3F F800-3F FOFF 
3F FA00-3F FBFF 
3F FCO0-3F FDFF 
3F FA00-3F FFFF 


00 000 000-00 000 777 
00 001 000-00 001 777 
00 002 000-00 002 777 
00 003 000-00 003 777 
00 004 000-00 004 777 
00 005 000-00 005 777 
00 006 000-00 006 777 
00 007 000-00 007 777 


17 774 000-17 774 777 
17 775 000-17 775 777 
17 776 000-17 776 777 
17 776 000-17 777 777 


The Q22-bus map registers (QMRs) have the format shown in Figure 9-2. 


Figure 9-2 Q22-bus Map Register Format 
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Table 9-2 describes the bits in the Q22—bus map register. 


Table 9-2 Q22-bus Map Register Bit Description 


Data Bit 


Name Description 


<31> 


<30:20> 


<19:0> 


Vv Valid. Read/write. When a Q22-bus map register is 
selected by bits <21:9> of the Q22—bus address, the valid bit 
determines whether mapping is enabled for that Q22—bus 
page. 


If the valid bit is set, the mapping is enabled, and Q22-bus 
addresses within the page controlled by the register are 
mapped into the main memory page determined by bits 
<28:9>. 


If the valid bit is clear, the mapping register is disabled, 
and the Q22-bus interface does not respond to addresses 
within that page. This bit is undefined on powerup and the 
negation of DCOK. 


Unused These bits always read as zeros and must be written as 
Zeros. 


A28-A9 Address bits <28:9> read/write. When a Q22—bus map 
register is selected by a Q22-bus address, and if that 
register’s valid bit is set, then these 20 bits are used as 
main memory address bits. 


Q22-bus address bits <8:0> are used as main memory 
address bits <8:0>. These bits are undefined on powerup 
and the negation of DCOK. 


9.1.2 Accessing the Q22-bus Map Registers 


Although the CPU accesses the Q22—bus map registers with aligned, longword 
references to the local I/O page (addresses 2008 8000 - 2008 FFFCjg), the map 
actually resides in a 32 KB block of main memory. The starting address of 

this block is controlled by the contents of the Q22—bus map base register. The 
Q22-bus interface also contains a 16-entry, fully associative, Q22—bus map cache 
to reduce the number of main memory accesses required for address translation. 


Note 


The system software must protect the pages of memory that contain the 
Q22-bus map from direct accesses that will corrupt the map or cause 
the entries in the Q22—bus map cache to become stale. Either of these 
conditions will result in the incorrect operation of the mapping function. 


When the CPU accesses the Q22—bus map through the local I/O page addresses, 
the Q22-bus interface reads or writes the map in main memory. The Q22-bus 
bus interface does not have to gain Q22—bus mastership when accessing the 
Q22-bus map. Because these addresses are in the local I/O space, they are not 
accessible from the Q22-bus. 
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On a Q22-bus map read by the CPU, the Q22-bus interface decodes the local I/O 
space address (2008 8000 - 2008 FFFCj¢). If the register is in the Q22—bus map 
cache, the Q22-bus interface will internally resolve any conflicts between CPU 
and Q22-bus transactions (if both are attempting to access the Q22—bus map 
cache entries at the same time), then return the data. Ifthe map register is 
not in the map cache, the Q22-bus interface will force the CPU to retry, acquire 
the CP- bus, and perform an asynchronous DMA read of the map register. On 
completion of the read, the CPU is provided with the data when its read operation 
is retried. A map read by the CPU does not cause the register that was read to 
be stored in the map cache. 


On a Q22-bus map write by the CPU, the Q22-bus interface latches the data. 
On completion of the CPU write, it acquires the CP- bus and performs an 
asynchronous DMA write to the map register. If the map register is in the 
Q22-bus map cache, then the CAMValid bit for that entry will be cleared to 
prevent the entry from becoming stale. A Q22—bus map write by the CPU does 
not update any cached copies of the Q22—-bus map register. 


9.1.3 The Q22—bus Map Cache 


To speed up the process of translating Q22—bus address to main memory 
addresses, the Q22-bus interface utilizes a fully associative, 16-entry, Q22—bus 
map cache that is implemented in the CQBIC chip. 


The cached copy of the Q22—bus map register is used for the address translation 
process. If the required map entry for a Q22—bus address (as determined by 

bits <21:9> of the Q22—bus address) is not in the map cache, then the Q22-bus 
interface uses the contents of the map base register to access main memory and 
retrieve the required entry. After obtaining the entry from main memory, the 
valid bit is checked. If it is set, the entry is stored in the cache and the Q22-bus 
cycle continues. Figure 9-3 shows the format. Table 9-3 contains a description of 
the Q22-bus map cache entry bits. 


Figure 9-3 Q22-bus Map Cache Entry Format 
3 3 21 
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Table 9-3 Q22-bus Map Cache Entry Bit Description 


Data Bit 


Name 


Description 


<33> 


<32:20> 


<19:0> 


CAMValid 


QBUS ADR 


Address bits 
A28-A9 


When a mapping register is selected by a Q22-bus address, the CAMValid 
bit determines whether the cached copy of the mapping register for that 
address is valid. 


If the CAMValid bit is set, the mapping register is enabled, and addresses 
within that page can be mapped. If the CAMValid bit is clear, the 
Q22-bus interface must read the map in local memory to determine if 
the mapping register is enabled. 


This bit is cleared on powerup, the negation of DCOK, setting the 
QMCIA (Q22-bus map cache invalidate all) bit in the interprocessor 
communication register, writes to IPR 55 (IORESET), by a write to the 
Q22-bus map base register, or by writing to the QMR that is being 
cached. 


These bits contain the Q22-bus address bits <21:9> of the page that this 
entry maps. This is the content addressable field of the 16-entry cache for 
determining if the map register for a particular Q22—bus address is in the 
map cache. These bits are undefined on powerup. 


When a mapping register is selected by a Q22-bus address, and if that 
register’s CAMValid bit is set, then these 20 bits are used as main 
memory address bits 28 through 9. Q22-bus address bits 8 through 0 are 
used as local memory address bits 8 through 0. These bits are undefined 
on powerup. 


9.2 CP to Q22—bus Address Translation 


CPbus addresses within the local Q22—bus I/O space, addresses 2000 0000 - 2000 
1FFF jg, are translated into Q22—bus I/O space addresses by using bits <12:0> of 
the CP- bus address as bits <12:0> of the Q22—bus address and asserting BBS7. 
Q22-bus address bits <21:13> are driven as zeros. 


CP- bus addresses within the local Q22—bus memory space, addresses 3000 0000 
- 303F FFFF j¢, are translated into Q22—bus memory space addresses by using 
bits <21:0> of the CP- bus address as bits <21:0> of the Q22-bus address. 
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9.3 Interprocessor Communications Facility 
The KA680 can only be configured as a Q22-bus arbiter. 


The KA680 interprocessor communication facility allows other processors on 

the Q22-bus to request program interrupts from the KA680 without using the 
Q22-bus interrupt request lines. It also controls external access to local memory 
(via the Q22—bus map). 


9.3.1 Interprocessor Communication Register (IPCR) 


The interprocessor communication register is a 16-bit register residing in the 
Q22-bus I/O page address space, and can be accessed by any device that can 
become Q22-bus master (including the KA680 itself). The IPCR is implemented 
in the CQBIC chip and is byte accessible, meaning that a write byte instruction 
can write to either the low or high byte without affecting the other byte. 
Figure 9—4 shows the format. Table 9—4 describes the bits. 


Figure 9-4 Interprocessor Communication Register (IPCR) 
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Table 9-4 Interprocessor Communication Register Bit Description 


Data Bit Name Description 


<15> DMA QME DMA Q22-bus address space memory error. Read/write to clear. This bit 
indicates that an error occurred when a Q22-bus device was attempting 
to read main memory. 


It is set if DMA system error register bit DSER<4> (MAIN MEMORY 
ERROR) is set, or the CP timer expires. The MAIN MEMORY ERROR 
bit indicates that an uncorrectable error occurred when an external device 
(or CPU) was accessing the KA680 local memory. 


(continued on next page) 
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Table 9-4 (Cont.) Interprocessor Communication Register Bit Description 


Data Bit 


Name 


Description 


<14> 


<13:09> 


<8> 


<7> 


<6> 


<5> 


<4:1> 


<0> 


QMCIA 


Unused 
AUX HLT 


Unused 
DBI IE 


LM EAE 


Unused 
DBI RQ 


The CP timer expiring indicates that the memory controller did not 
respond when the Q22-bus interface initiated a DMA transfer. This bit is 
cleared by writing a one to it, on powerup, by the negation of DCOK, by 
writes to IPR 55 (IORESET), and whenever DSER<4> is cleared. 


Q22-bus map cache invalidate all. Write-only. Writing a one to this bit 
clears the CAMValid bits in the cached copy of the MAP. This bit always 
reads as zero. Writing a zero has no effect. 


Read as zeros. Must be written as zeros. 


Auxiliary halt. Read-only. When this bit is set, it has no effect on the 
operation of the on-board CPU. This bit is cleared on powerup, by the 
negation of DCOK, and by writes to IPR 55 (IORESET). Note: This 
bit should never be set because the processor does not support 
auxiliary mode. 


Read as zero. Must be written as zero. 


Doorbell interrupt enable. Read/write when the KA680 is Q22-bus 
master. Read-only when another device is Q22—bus master. When set, 
this bit enables interprocessor doorbell interrupt requests via IPCR<0>. 
Cleared on powerup, by the negation of DCOK, and writes to IPR 55 
(IORESET). 


Local memory external access enable. Read/write when the KA680 is 
Q22-bus master. Read-only when another device is Q22—bus master. 
When set, this bit enables external access to local memory (via the 
Q22-bus map). Cleared on powerup and by the negation of DCOK. 


Read as zeros. Must be written as zeros. 


Doorbell interrupt request. Read/write. If IPCR<6> (DBI IE) is set, 
setting this bit generates a doorbell interrupt request. If IPCR<6> is 
clear, setting this bit has no effect. Clearing this bit has no effect. DBI 
RQ is cleared when the CPU grants the doorbell interrupt request. DBI 
RQ is held clear whenever DBI IE is clear. This bit is cleared on powerup 
and the negation of DCOK. 


9.3.2 Interprocessor Doorbell Interrupts 


If the interprocessor communication register DBI IE bit is set, any Q22—bus 
master can request an interprocessor doorbell interrupt by writing a one into 


IPCR bit <0>. 


The interrupt vector is 204;g and the interrupt priority is 14g. This IPL is 
the same as BR4 on the Q22-bus. The interprocessor doorbell is the third 
highest priority IPL 14 device, directly after the console serial line unit and the 
programmable timers. 


Note 


Following an interprocessor doorbell interrupt, the KA680 CPU sets the 
IPL to 14. The IPL is set to 17 for external Q22—bus BR4 interrupts. 
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9.4 Q22-bus Interrupt Handling 


The KA680 responds to interrupt requests BR7-4 with the standard Q22—bus 
interrupt acknowledge protocol (DIN followed by IAK). The console serial line 
unit, the programmable timers, and the interprocessor doorbell request interrupt 
at IPL 14 and have priority over all Q22—bus BR4 interrupt requests. After 
responding to any interrupt request BR7-4, the CPU sets the processor priority 
to IPL 17. All BR7-4 interrupt requests are disabled unless software lowers the 
interrupt priority level. 


Interrupt requests from the KA680 interval timer are handled directly by the 
CPU. Interval timer interrupt requests have a higher priority than BR6 interrupt 
requests. After responding to an interval timer interrupt request, the CPU sets 
the processor priority to IPL 16. Thus, BR7 interrupt requests remain enabled. 


9.5 Configuring the Q22—bus Map 


The KA680 implements the Q22—bus map in an 8K longword (32 KB) block of 
main memory. This map must be configured by the KA680 firmware during a 
processor initialization by writing the base address of the uppermost 32 KB block 
of good main memory into the Q22—bus map base register. The base of this map 
must be located on a 32 KB boundary. 


Note 


This 32 KB block of main memory must be protected by the system 
software. The only access to the map should be through local I/O page 
addresses, 2008 8000 - 2008 FFFC 46. 


9.5.1 Q22-—bus Map Base Address Register (Q@8MBR) 


The Q22-bus map base address register, address 2008 001016, controls the main 
memory location of the 32 KB block of Q22—bus map registers. This read/write 
register is accessible by the CPU on a longword boundary only. Bits <31:29,14:0> 
are unused and should be written as zeros, and will return zeros when read. 
Figure 9-5 shows the format. 


A write to the map base register will flush the Q22—bus map cache by clearing 
the CAMValid bits in all the entries. 


The contents of this register are undefined on powerup and the negation of 
DCOK, and are not affected by BINIT being asserted on the Q22-bus. 


Figure 9-5 Q22-bus Map Base Address Register (QBMBR) 
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Figure 9-6 System Configuration Register (SCR) 
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9.6 System Configuration Register (SCR) 


The system configuration register, address 2008 000046, contains the processor 
number that determines the address of the IPCR register, a BHALT enable bit, 
a power OK flag, and an AUX flag. Figure 9-6 shows the format. Table 9-5 
describes the bits in the system configuration register. 


The system configuration register (SCR) is longword, word, and byte accessible. 
Programmable option fields are cleared on powerup and by the negation of DCOK 
when SCR<7> is clear. 


Table 9-5 System Configuration Register Bit Description 


Data Bit Name Description 

<31:16> Unused Read as zeros. Must be written as zeros. 

<15> POK Power OK. Read-only. Writes have no effect. This bit is set if the Q22—bus 
BPOK signal is asserted and clear if it is negated. This bit is cleared on 
powerup and by the negation of DCOK. 

<14> BHALT EN BHALT enable. Read/write. This bit controls the effect the Q22—bus 


BHALT signal has on the CPU. When set, asserting the Q22—-bus BHALT 
signal will halt the CPU and assert DSER<15>. When cleared, the 
Q22-bus BHALT signal will have no effect. This bit is cleared on powerup 
and by the negation of DCOK. 


(continued on next page) 
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Table 9-5 (Cont.) System Configuration Register Bit Description 


Data Bit Name Description 
<10> AUX Auxiliary. Read-only. Writes have no effect. This bit defines auxiliary 
and arbiter mode of operation of the KA680. When read as a zero, arbiter 
mode is selected, and when read as a one, auxiliary mode is selected. 
Because the KA680 can only be configured as an arbiter, this bit should 
always read as zero. 
<9:8> Unused Read as zeros. Must be written as zeros. 
<7> ACTION Read/write. When cleared, the Q22-bus interface asserts SYSRESET 
ON DCOK (causing a hardware reset of the board and control to be passed to the 
NEGATION resident firmware via the hardware halt procedure with a halt code of 3) 
when DCOK is negated on the Q22-bus. When set, the Q22-bus interface 
asserts HALCYON (causing control to be passed to the resident firmware 
via the hardware halt procedure with a halt code of 2) when DCOK is 
negated on the Q22-bus. Cleared on powerup and the negation of DCOK. 
<6:4> Unused Read as zeros. Must be written as zeros. 
<3:1> Unused Read as zeros. Must be written as zeros. 
<0> Unused Read as zero. Must be written as zero. 


9.7 Error Reporting Registers 

There are three registers associated with Q22-bus interface error reporting: 
¢ The DMA system error register (DSER) 

¢ The Q22-bus error address register (QBEAR) 

¢ The DMA error address register (DEAR) 


These registers are located in the local VAX I/O address space and can only 

be accessed by the local processor. The DSER is implemented in the CQBIC 
chip and it logs main memory errors on DMA transfers, Q22-bus parity errors, 
Q22-bus nonexistent memory errors, and Q22-bus no-grant. The QBEAR 
contains the address of the page in Q22-bus space that caused a parity error 
during an access by the local processor. The DEAR contains the address of the 
page in local memory, which caused a memory error during an access by an 
external device or the processor during a local-miss, global-hit transaction. An 
access by the local processor that the Q22—bus interface maps into main memory 
will provide error status to the processor when the processor does a retry for a 
read local-miss, global-hit, or by an interrupt in the case of a local-miss, global-hit 


write. 


9.7.1 DMA System Error Register (DSER) 


The DSER (address 2008 000416) is a longword, word, or byte accessible 
read/write register available to the local processor. The bits in this register 

are cleared to zero on powerup, by the negation of DCOK, and by writes to IPR 
55 (IORESET). All bits are set to one to record the occurrence of an event. They 
are cleared by writing a one; writing zeros has no effect. 
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The format of the DMA system error register is shown in Figure 9-7. Table 9-6 
describes the bits in the system error register. 
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Figure 9-7 DMA System Error Register (DSER) 
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Table 9-6 DMA System Error Register Bit Description 


Data Bit 


Name 


Description 


<31:16> 
<15> 


<14> 


<13:8> 


<7> 


<6> 


<5> 


<4> 


<3> 


<2> 


<1:0> 


Unused 
Q22-BUS BHALT DETECTED 


Q22-BUS DCOK NEGATION 
DETECTED 


Unused 
MASTER DMA NXM 


Unused 
Q22-bus PARITY ERROR 


MAIN MEMORY ERROR 


LOST ERROR 


NO GRANT TIMEOUT 


Unused 


Read as zeros. Must be written as zeros. 


Read/write to clear. This bit is set when the Q22-bus 
interface detects that the Q22—bus BHALT line was 
asserted and SCR<14> (BHALT ENABLE) is set. 
Cleared by writing a one, writes to IPR 55 (IORESET), 
on powerup, and the negation of DCOK. 


Read/write to clear. This bit is set when the Q22-bus 
interface detects the negation of DCOK on the Q22-bus 
and SCR<7> (ACTION ON DCOK NEGATION) is set. 
Cleared by writing a one, writes to IPR 55 (IORESET), 
on powerup, and the negation of DCOK. 


Read as zeros. Must be written as zeros. 


Read/write to clear. This bit is set when the CPU 
performs a demand Q22-bus read cycle or write cycle 
that does not reply after 10 ps. During interrupt 
acknowledge cycles, or request read cycles, this bit is 
not set. Cleared by writing a one, on powerup, by the 
negation of DCOK, and by writes to IPR 55 (IORESET). 


Read as zero. Must be written as zero. 


Read/write to clear. This bit is set when the CPU 
performs a Q22-bus demand read cycle that returns 

a parity error. During interrupt acknowledge cycles or 
request read cycles, this bit is not set. Cleared by writing 
a one, on powerup, by the negation of DCOK, and by 
writes to IPR 55 (IORESET). 


Read/write to clear. This bit is set if an external Q22—bus 
device or local-miss, global-hit receives a memory error 
while reading local memory. The IPCR<15> reports the 
memory error to the external Q22—bus device. Cleared 
by writing a one, on powerup, by the negation of DCOK, 
and by writes to IPR 55 (IORESET). 


Read/write to clear. This bit indicates that an error 
address has been lost because of DSER<7,5,4,0> having 
been previously set and a subsequent error of either type 
occurs, which would have normally captured an address 
and set either DSER<7,5,4,0> flag. Cleared by writing a 
one, on powerup, by the negation of DCOK, and by writes 
to IPR 55 (IORESET). 


Read/write to clear. This bit is set if the Q22—bus does 
not return a bus grant within 10 ms of the bus request 
from a CPU demand read cycle or write cycle. During 
interrupt acknowledge or request read cycles, this bit is 
not set. Cleared by writing a one, on powerup, by the 
negation of DCOK, and by writes to IPR 55 (IORESET). 


Read as zeros. Must be written as zeros. 


9.7.2 Q22-bus Error Address Register (QBEAR) 


The Q22-bus error address register, address 2008 000816, is a read-only, 
longword-accessible register that is implemented in the CQBIC chip. Its contents 
are valid only if DSER<5> (Q22-BUS PARITY ERROR) is set, or if DSER<7> 


(MASTER DMA NXM) is set. 
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Reading this register when DSER<5> and DSER<7> are clear will return 
undefined results. Additional Q22—bus parity errors that could have set 
DSER<5> or Q22-bus timeout errors that could have caused DSER<7> to 
set, will cause DSER<3> to set. 


The QBEAR contains the address of the page in Q22—bus space that caused a 
parity error during an access by the on-board CPU, which set DSER<5>, or a 
master timeout, which set DSER<7>. 


Q22-bus address bits <21:9> are loaded into QBEAR bits <12:0>. QBEAR bits 
<31:13> always read as zeros. 


Figure 9-8 Q22-bus Error Address Register (QBEAR) 
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Figure 9-9 DMA Error Address Register (DEAR) 
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Note 


This is a read-only register. If a write is attempted, a hard error (IPL 1D) 
will be generated. 


9.7.3 DMA Error Address Register (DEAR) 


The DMA error address register, address 2008 000Cj¢, is a read-only, longword- 
accessible register that is implemented in the CQBIC chip. It contains valid 
information only when DSER<4> (MAIN MEMORY ERROR) is set . 


The DEAR contains the map translated address of the page in local memory 
that caused a memory error or nonexistent memory error. This occurred during 
an access by an external device or the Q22—-bus interface for the CPU during a 
local-miss, global-hit transaction or Q22—bus map access. 


The contents of this register are latched when DSER<4> is set. Additional main 
memory errors or nonexistent memory errors have no effect on the DEAR until 
software clears DSER<4>. 


Mapped Q22-bus address bits <28:9> are loaded into DEAR bits <19:0>. DEAR 
bits <31:20> always read as zeros. 
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Note 


This is a read-only register. If a write is attempted, a hard error (IPL 1D) 
will be generated. 


9.8 Q22-bus Interface Error Handling 
The Q22-bus interface does not generate or check parity. 


The Q22-bus interface checks all CPU references to Q22—-bus memory and I/O 
spaces to ensure that nothing but masked and unmasked longword accesses are 
attempted. Any other type of reference will cause a machine check abort to be 
initiated. 


The Q22-bus interface maintains several timers to prevent incomplete accesses 
from hanging the system indefinitely. They include: a 10 ps nonexistent memory 
timer for accesses to the Q22—bus memory and I/O spaces, a 10 us "no sack" timer 
for acknowledgement of Q22—bus DMA grants, and a 10 ms "no grant” timer for 
acquiring the Q22-bus. 


If there is a nonexistent memory (NXM) error (10 us timeout) while accessing 
the Q22—bus on a demand read reference, bit DSER<7> is set, the address of the 
Q22-bus page being accessed is captured in QBEAR<12:0>, and a machine check 
abort is initiated. 


If there is an NXM error on a prefetch read, or an interrupt acknowledge vector 
read, then the prefetch or interrupt acknowledge reference is aborted but no 
information is captured and no machine check occurs. 


If there is an NXM error on a masked write reference, then DSER<7> is set, the 
address of the Q22-bus page being accessed is captured in QBEAR<12:0>, and an 
interrupt is generated at IPL 1D through vector 604g. 


If the Q22-bus interface does not receive an acknowledgement within 10 ps after 
it has granted the Q22-bus, the grant is withdrawn, no errors are reported, and 
the Q22-bus interface waits 500 ns to clear the Q22—bus grant daisy chain before 
beginning arbitration again. 


If the Q22-bus interface tries to obtain Q22—bus mastership on a CPU demand 
read reference, and does not obtain it within 10 ms, DSER<2> is set, anda 
machine check abort is initiated. 


The Q22-bus interface also monitors Q22—bus signals BDAL<17:16> while 
reading information over the Q22-bus so that parity errors detected by the device 
being read are recognized. 


If a parity error is detected by another Q22-bus device on a CPU demand read 
reference to Q22—bus memory or I/O space, then DSER<5> is set, the address of 
the Q22-bus page being accessed is captured in QBEAR<12:0>, and a machine 
check abort is initiated. 


If a parity error is detected by another Q22—bus device on a prefetch request 
read by the CPU, the prefetch is aborted, DSER<5> is set, and the address of the 
Q22-bus page being accessed is captured in QBEAR<12:0>, but no machine check 
is generated. 
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KA680 Q22-bus Interface 
9.8 Q22-bus Interface Error Handling 


The Q22-bus interface also monitors the backplane BPOK signal to detect power 
failures. If BPOK is negated on the Q22-bus, a power-fail trap is generated, 
and the CPU traps through vector 0Cjg. The state of the Q22—bus BPOK signal 
can be read from SCR<15>. The Q22-bus interface continues to operate after 
generating the power-fail trap, until DCOK is negated. 


KA680 Q22-bus Interface 9-17 


10 


Network Interface 


The includes a network interface that is implemented via the second generation 
Ethernet controller chip (SGEC). When used in conjunction with the cover 
panel, this interface allows the to be connected to either a ThinWire or standard 
Ethernet network. It supports the Ethernet data link layer as specified in the 
VAX Architecture Reference Manual. The SGEC also supports CP-bus parity 
protection. 


10.1 Ethernet Overview 


Ethernet is a serial bus that can support up to 1,024 nodes with a maximum 
separation of 2.8 kilometers (1.7 miles). Data is passed over the Ethernet in 
Manchester-encoded format at a rate of 10 million bits per second in variable- 
length packets. Each packet has the format shown in Figure 10-1. 
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Figure 10-1 Ethernet Packet Format 


6 bytes Destination Address 


6 bytes Source Address 


2 bytes 
46..1500 bytes Data 
4 bytes CRC Check Code 


ESB90P0051 


The minimum size of a packet is 64 bytes, which implies a minimum data length 
of 46 bytes. Packets shorter than this are called runt packets and are treated 
as erroneous when received by the network controller. 


All nodes on the Ethernet have equal priority. The technique used to control 
access to the bus is carrier sense, multiple access, with collision detection (CSMA 
/CD). To access the bus, devices must first wait for the bus to clear (no carrier 
sensed). Once the bus is clear, all devices that want to access the bus have 
equal priority (multiaccess), so they all attempt to transmit. After starting 
transmission, devices must monitor the bus for collisions (collision detection). If 
no collision is detected, the device may continue with transmission. If a collision 
is detected, then the device waits for a random amount of time and repeats the 
access sequence. 


Ethernet allows point-to-point communication between two devices, as well as 
simultaneous communication between multiple devices. To support these two 
modes of communication, there are two types of network addresses, physical and 
multicast. These two types of addresses are both 48 bits (6 bytes) long and are 
described below. 


Physical address: The unique address associated with a particular station on 
the Ethernet, which should be distinct from the physical address of any other 
station on any other Ethernet. 


Multicast address: A multidestination address associated with one or more 
stations on a given Ethernet (sometimes called a logical address). There are two 
kinds of multicast addresses: 
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Multicast-group address: An address associated by higher level convention to 
a group of logically related stations. 


Broadcast address: A predefined multicast address that denotes the set of all 
the stations on the Ethernet. 


Bit 0 (the least significant bit of the first byte) of an address denotes the type: 

it is 0 for physical addresses and 1 for multicast addresses. In either case, the 
remaining 47 bits form the address value. A value of 48 ones is always treated as 
the broadcast address. 


The hardware address of the module is determined at the time of manufacture 
and is stored in the network interface station address ROM. Because every device 
that is intended to connect to an Ethernet network must have a unique physical 
address, the bit pattern blasted into the network interface station address ROM 
must be unique for each . The multicast addresses to which the will respond 

are determined by the multicast address filter mask in the network interface 
initialization block. 


10.2 NI Station Address ROM (NISA ROM) 


The network interface includes a bytewide, 32-byte, socketted ROM called the 
network interface station address ROM. One byte of this ROM appears in the 
second byte of each of 32 consecutive longwords in the address range 2008 4000 

- 2008 407C 1g. Bytes one, three, and four of each longword are defined in the 
boot diagnostic register (Section 9.1). The second byte of the first six longwords 
contain the 48-bit network physical address (NPA) of the . The low-order byte in 
the remaining 26 longwords are used for testing. This address range is read-only. 
Writes to this address range will 


10.3 Programming the SGEC 


The operation of the SGEC is controlled by a program in host memory called 
the port driver. The SGEC and the port driver communicate through two data 
structures: network interface command and status registers (NICSRs) 
located in the SGEC and mapped in the host I/O address space, and through 
descriptor lists and data buffers (collectively called host communication 
area in host memory. 


The NICSRs are used for initialization, global pointers, commands, and global 
errors reporting, while the host memory resident structures handle the actions 
and statuses related to buffer management. 


The SGEC can be viewed as two independent, concurrently executing processes: 
reception and transmission. After the SGEC completes its initialization 
sequence, these two processes alternate between three states: STOPPED, 
RUNNING, or SUSPENDED. State transitions occur as a result of port driver 
commands (writing to an NICSR) or various external events occurrences. Some of 
the port driver commands require the referenced process to be in a specific state. 


A simple programming sequence of the chip may be summarized as: 
1. After power on (or reset), verifying the self test completed successfully. 


2. Writing NICSRs to set major parameters such as system base register, 
interrupt vector, address filtering mode, and so on. 


3. Creating the transmit and receive lists in memory and writing the NICSRs to 
identify them to the SGEC. 
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4. Placing a setup frame in the transmit list, to load the internal reception 
address filtering table. 


5. Starting the reception and transmission processes, placing them in the 
RUNNING state. 


6. Waiting for SGEC interrupts. NICSR5 contains all the global interrupt status 
bits. 


7. Remedying the suspension cause, if either of the reception or transmission 
processes enter the SUSPENDED state. 


8. Issuing a Tx Poll Demand command, to return the transmission process to 
the RUNNING state. In addition, to remedy the reception process suspension 
cause, an Rx Poll Demand could be issued to return the reception process to 
the RUNNING state. 


If the Rx Poll Demand is not issued, the reception process will return to 
the RUNNING state when the SGEC receives the next recognized incoming 
frame. 


The following sections contain detailed programming and state transition 
information. 

10.3.1 Command and Status Registers 
The SGEC contains 16 command and status registers, which may be accessed by 
the host. 

10.3.2 Host Access to NICSRs 
The SGEC’s NICSRs are located in VAX I/O address space. 


The NICSRs must be longword-aligned and can only be accessed using 
longword instructions. The address of NICSRx is the base address plus 4x 
bytes. For example, if the base address is 2000 8000, then the address of NICSR2 
is 2000 8008. In the following paragraphs, NICSR bits are specified with several 
access modes. The different access modes for bits are as follows: 


Table 10-1 Bit Access Modes 


Bit Marked Meaning 

0 Reserved for future expansion - ignored on write, read as “0” 

1 Reserved for future expansion - ignored on write, read as “1” 

R Read-only, ignored on write 

R/W Read or write 

WwW Write-only, unpredictable on read 

R/W1 Read, or clear by writing a “1” - writing with a “0” has no effect 


In order to save chip real estate, yet not tie up the host bus for extended periods 
of time, the 16 NICSRs are subdivided into two groups: 


1. Physical NICSRs - 0 through 7, 15 
2. Virtual NICSRs - 8 through 14 
The group in which the NICSR is part, determines the way the host will access it. 
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10.3.2.1 Physical NICSRs 
These registers are physically present in the chip. Host access to these NICSRs 
is by a single instruction (for example, MOVL). There is no host perceivable delay 
and the instruction completes immediately. Most commonly used SGEC features 
are contained in the physical NICSRs. 


10.3.2.2 Virtual NICSRs 


These registers are not physically present in the SGEC and are incarnated by 
the on-chip processor. Accesses to SGEC functions implied by these registers may 
take up to 20 useconds. In order not to tie up the host bus, virtual NICSR access 
requires several steps by the host. 


NICSR5<DN> is used to synchronize access to the virtual NICSRs: after the first 
virtual NICSR access, the SGEC deasserts NICSR5<DN> until it will complete 
the action. 


Note 


Accessing the virtual NICSRs, without polling first on the NICSR5<DN> 
reassertion, will cause unpredictable results. 


10.3.2.2.1 NICSR Write To write to a virtual NICSR, the host takes the 
following actions: 


1. Issues a write NICSR instruction. Instruction completes immediately, but the 
data is not yet copied by the SGEC. 


2. Waits for NICSR5<DN>. No SGEC virtual NICSR may be accessed before 
NICSR5<DN?> asserts. 


10.3.2.2.2 NICSR Read _ To read a virtual NICSR, the host takes the following 
actions: 


1. Issues a read NICSR instruction. Instruction completes immediately, but no 
valid data is sent to the host. 


2. Waits for NICSR5<DN>. No SGEC virtual NICSR may be accessed before 
NICSR5<DN?> asserts. 


3. Reissues a read NICSR instruction to the same NICSR as in step 1. The host 
receives valid data. 
10.3.3 Vector Address, IPL, Sync/Async (NICSRO) 


Because the SGEC may generate an interrupt on parity errors during host writes 
to NICSRs, this register must be the first one written by the host. The format is 
shown in Figure 10-2 and the bit description is given in Table 10-2. 
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Figure 10-2 Vector Address, IPL, Sync/Async (NICSRO) 


1 
09876543210 


i | | Must Be One IV — Interrupt Vector 


/O Address: 2000 8000 
(16) 


Longword Read/Write Access 
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Note 


A parity error during NICSRO host write may cause a host system crash 
due to an erroneous interrupt vector. To prevent a crash, NICSRO must 
be written as follows while the IPL (to which the SGEC is assigned) is 
disabled: 


1. Write NICSRO. 
2. Read NICSRO. 


3. Compare value read to value written. If values do not match, repeat 
the procedure starting with step 1. 


4. Read NICSR5 and examine NICSR5<ME> for pending parity 
interrupt. Should an interrupt be pending, write NICSR5 to clear 
it. 
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Bit Name Access 


Description 


<31:30> IP R/W 


<29> SA R/W 


<15:00> IV R/W 


Interrupt priority - the VAX interrupt priority 
level to which the SGEC will respond. 


IP IPL (hex) 


00 14 
01 15 
10 16 
11 17 


Although the SGEC has only one interrupt 
request pin, that pin might be wired to any of the 
four IRQ pins on the host. The value in IP should 
be 1416 for the KA690. 


Sync/Async - This bit determines the SGEC 
operating mode when it is the bus master. When 
set, the SGEC will operate as a synchronous 
device and when clear, the SGEC will operate as 
an asynchronous device. 


Interrupt vector - During an interrupt 
acknowledge cycle for an SGEC interrupt, this is 
the value that the SGEC will drive on the host 
bus CDAL<31:0> pins (CDAL pins <1:0> and 
<31:16> are set to “0”). Bits <1:0> are ignored 
when NICSRO is written, and set to “1” when 
read. 


Table 10-3 NICSRO Access 


Value after RESET: 1FFF0003 hex 
Read access rules: None 
Write access rules: The IPL to which the SGEC is assigned must be DISABLED 


The Polling Demand NICSR (NICSR1) is used by the port driver to tell the SGEC 
that it put a packet on the transmit or receive list. The format is shown in 
Figure 10-3 and the bit description is in Table 10-4. 


Figure 10-3 Polling Demand (NICSR1) 


3322222222221 
1098765432109 


I/O Address: 2000 8004 
16 


Longword Write Only Access 


1 
09876543210 


L pp 
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Table 10-4 NICSR1 Bits 


Bit Name Access Description 

<31:01> MBZ - Must be one. This field is reserved for future 
expansion. Write as ONE. 

<00> PD W Tx Polling Demand - Checks the transmit list for 


frames to be transmitted. 
The PD value is meaningless. 


Table 10-5 NICSR1 Access 


Value after RESET: Not applicable 
Read access rules: None 
Write access rules: Tx process SUSPENDED 


10.3.4 Receive Polling Demand (NICSR2) 


Figure 10-4 NICSR2 Format 


L pp 
I/O Address: 2000 8008 
(16) 

ESB90P0054 
Table 10-6 NICSR2 Bits 
Bit Name Access Description 
<31:01> MBO - Must be one. This field is reserved for future 

expansion. Write as ONE. 

<00> PD W Rx Polling Demand - Checks the receive list for 


receive descriptors to be acquired. 
The PD value is meaningless. 


Table 10-7 NICSR2 Access 


Value after RESET: Not applicable 
Read access rules: None 
Write access rules: Rx process SUSPENDED 
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10.3.5 Descriptor List Addresses (NICSR3, NICSR4) 


The two descriptor list address registers are identical in function, one being used 
for the transmit buffer descriptors and one being used for the receive buffer 
descriptors. In both cases, the registers are used to point the SGEC to the start 
of the appropriate buffer descriptor list. 


The descriptor lists reside in VAX physical memory space and must be 
longword-aligned. 


Note 


For best performance, it is recommended that the descriptor lists be 
octaword-aligned. 


Transmit List 


If the transmit descriptor list is built as a ring (the chain descriptor 
points at the first descriptor of the list), the ring must contain, at least, 
two descriptors in addition to the chain descriptor. 


Initially, these registers must be written before the respective Start 
command is given (see Section 10.3.7), or the respective process will remain 

in the STOPPED state. New list head addresses are only acceptable while the 
respective process is in the STOPPED or SUSPENDED state. Addresses written 
while the respective process is in the RUNNING state are ignored and discarded. 


If the host attempts to read any of these registers before ever writing to them, 
the SGEC responds with unpredictable values. 
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Figure 10-5 Descriptor List Addresses Format 


3.3 
1 0 2 10 


MBZ Start of Receive List - RBA MBZ NICSR3 


I/O Address: 2000 800C 
(16) 


Longword Read/Write Access 


3.3 
1 0 210 


MBZ Start of Transmit List - TBA MBZ NICSR4 


/O Address: 2000 8010 
(16) 


Longword Read/Write Access 
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Table 10-8 Descriptor List Addresses Bits 


Bit Name Access Description 
<31:30> MBZ = Must be zero. Ignored on writes, read as zero. 
<29:00> RBA or TBA R/W Address of the start of the receive list (NICSR3) 


or transmit list (NICSR4). This is a 30-bit VAX 
physical address. 


Note 


The descriptor lists must be longword-aligned. 


Table 10-9 NICSR3 Access 


Value after RESET: Unpredictable 
Read access rules: None 
Write access rules: Rx process STOPPED or SUSPENDED 


Table 10-10 NICSR4 Access 


Value after RESET: Unpredictable 
Read access rules: None 
Write access rules: Tx process STOPPED or SUSPENDED 
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After NICSR3 or NICSR4 is written, the new address is readable from the written 
NICSR. However, if the SGEC status did not match the related write access rules, 
the new address does not take effect and the written information is lost, even if 
the SGEC matches the right condition later. 


10.3.6 Status Register (NICSR5) 


This register contains all the status bits the SGEC reports to the host. 
Figure 10-6 shows the register format and Table 10—11 describes the register 
bits. 


Figure 10-6 NICSR5 Bits 


a ae a | 
98765 76543210 


BO 
DN 
SF 
ID 
I/O Address: 2000 8014 
(16) 
Longword Access with: 
Bits <31:16> Read Only 
Bits <16:0> Read/Write One to Clear 
ESB90P0056 
Table 10-11 NICSR5 Bits 
Bit Name Access Description 
<31> ID R Initialization done - When set, indicates the 


SGEC has completed the initialization (reset 
and self-test) sequences, and is ready for further 
commands. 


When clear, indicates the SGEC is performing 
the initialization sequence and ignoring all 
commands. 


After the initialization sequence completes, the 
transmission and reception processes are in the 
STOPPED state. 


(continued on next page) 


Network Interface 10-11 


Network Interface 


10.3 Programming the SGEC 


Table 10-11 (Cont.) NICSR5 Bits 


Bit Name Description 
<30> SF Self-test failed - When set, indicates the SGEC 
self-test has failed. 
The self-test completion code bits indicate the 
failure type. 
<29:26> SS Self-test status - The self-test completion code, 
according to the following table, is only valid if 
SF is set. 
Value Meaning 
0001 ROM error 
0010 RAM error 
0011 Address filter RAM error 
0100 Transmit FIFO error 
0101 Receive FIFO error 
0110 Self-test loopback error 
Information 
Self-test takes 25 
ms to complete after 
hardware or software 
RESET. 
<25:24> TS Transmission process state - Indicates the current 
state of the transmission process, as follows: 
Value Meaning 
00 STOPPED 
01 RUNNING 
10 SUSPENDED 
Section 10.3.18.5 explains the transmission 
process operation and state transitions. 
<23:22> RS Reception process state - Indicates the current 


10-12 Network Interface 


state of the reception process, as follows: 


Value Meaning 

00 STOPPED 

01 RUNNING 

10 SUSPENDED 


Section 10.3.18.4 explains the reception process 
operation and state transitions. 


(continued on next page) 
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Bit Name Access Description 
<18:17> OM R Operating mode - These bits indicate the current 
SGEC operating mode, as follows: 
Value Meaning 
00 Normal operating mode. 
01 Internal loopback - Indicates the 
SGEC is disengaged from the 
Ethernet wire. 
Frames from the transmit list are 
looped back to the receive list, 
subject to address filtering. 
Section 10.3.18.6 explains this 
mode of operation. 
10 External loopback - Indicates the 
SGEC is working in full-duplex 
mode. 
Frames from the transmit list are 
transmitted on the Ethernet wire 
and also looped back to the receive 
list, subject to address filtering. 
Section 10.3.18.6 explains this 
mode of operation. 
11 Reserved for diagnostics 
<16> DN R Done - When set, indicates the SGEC has 
completed a requested virtual NICSR access. 
After a reset, this bit is set. 
<15:8> MBO - Must be one - This field is reserved. Writes are 
ignored, read as one. 
<7> BO R/W1 Boot_Message - When set, indicates that the 
SGEC has detected a boot_message on the serial 
line and has set the external pin BOOT_L. 
<6> TW R/W1 Transmit watchdog timer interrupt - When 
set, indicates the transmit watchdog timer has 
timed out, indicating the SGEC transmitter was 
babbling. The transmission process is aborted 
and placed in the STOPPED state. (Also reported 
into the Tx descriptor status TDES0<TO> flag). 
<5> RW R/W1 Receive watchdog timer interrupt - When set, 


indicates the receive watchdog timer has timed 
out, indicating that some other node is babbling 
on the network. 


Current frame reception is aborted, and 
RDESO<LE> and RDESO<LS> will be set. Bit 
NICSR5<RI> will also set. The reception process 
remains in the RUNNING state. 


(continued on next page) 
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Table 10-11 (Cont.) NICSR5 Bits 


Bit Name Access 


Description 


<4> ME R/W1 


<3> RU R/W1 


<2> RI R/W1 
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Memory error - Is set when any of the followings 
occur: 


e SGEC is the CP-bus master and the ERR_L 
pin is asserted by external logic (generally 
indicative of a memory problem). 


¢ Parity error detected on a host to SGEC 
NICSR write or SGEC read from memory. 


When a memory error is set, the reception and 
transmission processes are aborted and placed 
in the STOPPED state. 


Note ____— 


At this point, it is 
mandatory that the 
port driver issue a 
Reset command and 
rewrite all NICSRs. 


Receive buffer unavailable - When set, indicates 
that the next descriptor on the receive list is 
owned by the host and could not be acquired by 
the SGEC. 


The reception process is placed in the 
SUSPENDED state. Section 10.3.18.4 explains 
the reception process state transitions. Once 

set by the SGEC, this bit will not be set again 
until the SGEC encounters a descriptor it cannot 
acquire. 


To resume processing receive descriptors, the host 
must flip the ownership bit of the descriptor and 
can issue the Rx Poll Demand command. If no 
Rx Poll Demand is issued, the reception process 
resumes when the next recognized incoming 
frame is received. 


Receive interrupt - When set, indicates that a 
frame has been placed on the receive list. Frame- 
specific status information was posted in the 
descriptor. The reception process remains in the 
RUNNING state. 
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Table 10-11 (Cont.) NICSR5 Bits 
Bit Name Access Description 


<1> TI R/W1 Transmit interrupt - When set, indicates one of 
the following: 


e Either all the frames in the transmit list 
have been transmitted (next descriptor 
owned by the host), or a frame transmission 
was aborted due to a locally induced 
error. The port driver must scan the list 
of descriptors to determine the exact cause. 


The transmission process is placed in the 
SUSPENDED state. Section 10.3.18.5 
explains the transmission process state 
transitions. To resume processing transmit 
descriptors, the port driver must issue the 
Poll Demand command. 


e A frame transmission completed, and 
TDES1<IC> was set. The transmission 
process remains in the RUNNING state, 
unless the next descriptor is owned by the 
host or the frame transmission aborted 
due to an error. In the latter cases, the 
transmission process is placed in the 
SUSPENDED state. 


<0> IS R/W1 Interrupt summary - The logical “OR” of NICSR5 
bits 1 through 6. 


Table 10-13 NICSR5 Access 


Value after RESET: 0039FF00 hex 
Read access rules: None 
Write access rules: NICSR5<07:01> bits cleared by 1, others bits not writable 


10.3.6.1 NICSR5 Status Report 
The status register NICSR5 is split into two words: 
¢ The high word, which contains the global status of the SGEC as the 


initialization status, the DMA and operation mode, and the receive and 
transmit process states. 


¢ The low word, which contains the status related to the receive and transmit 
frames. 


Any change of the NICSR5 bits <ID>, <SF>, <OM> or <DN>, which is always the 
result of a host command, is reported without an interrupt. 


Any process state change initiated by a host command NICSR6<ST> or 
NICSR6<SR> is reported without an interrupt. 


In the above two cases, the driver must poll on NICSR5 to get the acknowledge 
of its command (for example, polling on <ID, SF> after Reset or polling on <TS> 
after a START_TX command). 
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Any process state change initiated by the SGEC activity is immediately 
followed by at least one of the NICSR5<6:1> interrupts and the interrupt_ 
summary NICSR5<IS>. 


The SGEC 16-bit internal processor updates the 32-bit NICSR5 register in two 
phases: the high word is modified first, then the low word is written, which 
generates an interrupt to the host. In this case, the driver must scan first the 
NICSR5 low word to get the interrupt status, then the NICSR high word to get 
the related process state. For example, <TI> interrupt with <TS> = SUSPENDED 
reports an end of transmission due to a Tx descriptor unavailable. 


If the host polls on the process state change, it may detect a change without 
interrupt, due to the small time window separating the NICSR5 high word and 
low word updates. 


Maximum time window is 4 * Tcycles of the host clock. 


10.3.7 Command and Mode Register (NICSR6) 


This register is used to establish operating modes and for port driver commands. 


Figure 10-7 NICSR6 Format 


4 he ey ly At 
eee eee eee ee 


{ 
7 
Must S$|S}] OM |DIF AF 
be ONE |T|R cic 


/O Address: 2000 8018 
(16) 


Longword Read/Write Access 


r = reserved 
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Table 10-14 NICSR6 Bits 

Bit Name Access Description 

<31> RE R/W Reset command - Upon being set, the SGEC will abort all processes 


and start the reset sequence. After completing the reset and self-test 
sequence, the SGEC will set bit NICSR5<ID>. Clearing this bit has no 


effect. 
Note 
The NICSR6<RE> value is unpredictable 
on read after hardware reset. 
<30> TE R/W Interrupt enable mode - When set, setting of NICSR5 bits 1 through 6 


will cause an interrupt to be generated. 


(continued on next page) 
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Table 10-14 (Cont.) NICSR6 Bits 


Bit Name Access Description 

<29> r - Reserved 

<28:25> BL R/W Burst limit mode - Specifies the maximum number of longwords to be 
transferred in a single DMA burst on the host bus. 
When NICSR6<SE> is cleared, permissible values are 1,2,4,8. When 
SE is set, the only permissible values are 1 and 4; a value of 2 or 8 is 
respectively forced to 1 or 4. 
After initialization, the burst limit is set to 1. 

<24:21> MBO - This field is reserved. Writes are ignored, read as one. 

<20> BE R/W Boot_message enable mode - When set, enables the boot_message 
recognition. When the SGEC recognizes an incoming boot message 
on the serial line, NICSR5<BO> is set and the external pin BOOT_L is 
asserted for a duration of 6*Tcycles (of the host clock). 

<19> SE R/W Single_cycle enable mode - When set, the SGEC transfers only a single 
longword or an octaword in a single DMA burst on the host bus. 

<18:12> MBO - Must be one. This field is reserved. Writes are ignored, read as one. 

<1l> ST R/W Start/Stop Transmission command - When set, the transmission process 


is placed in the RUNNING state, the SGEC checks the transmit list at 
the current position for a frame to transmit (the address set by NICSR4 
or the position retained when the Tx process was previously stopped). 


If it does not find a frame to transmit, the transmission process enters 
the SUSPENDED state. The Start Transmission command is honored 
only when the transmission process is in the STOPPED state. The first 
time this command is issued, an additional requirement is that NICSR4 
has already been written to, or the transmission process will remain in 
the STOPPED state. 


When cleared, the transmission process is placed in the STOPPED state 
after completing transmission of the current frame. The next descriptor 
position in the transmit list is saved, and becomes the current position 
after transmission is restarted. 


The Stop Transmission command is honored only when the transmission 
process is in the RUNNING or SUSPENDED states. 


Refer to Section 10.3.18.5 for more information. 


(continued on next page) 
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Table 10-14 (Cont.) NICSR6 Bits 


Bit Name 


Access Description 


<10> SR 
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R/W 


Start/Stop Reception command - When set, the reception process is 
placed in the RUNNING state, and the SGEC attempts to acquire a 
descriptor from the receive list and process incoming frames. 


Descriptor acquisition is attempted from the current position in the list 
(the address set by NICSR3 or the position retained when the Rx process 
was previously stopped). If no descriptor can be acquired, the reception 
process enters the SUSPENDED state. 


The Start Reception command is honored only when the reception 
process is in the STOPPED state. The first time this command is issued, 
an additional requirement is that NICSR3 has already been written to, 
or the reception process will remain in the STOPPED state. 


When cleared, the reception process is placed in the STOPPED state 
after completing reception of the current frame. The next descriptor 
position in the receive list is saved, and becomes the current position 
after reception is restarted. The Stop Reception command is honored 
only when the reception process is in the RUNNING or SUSPENDED 
states. 


Refer to Section 10.3.18.4 for more information. 


(continued on next page) 
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Bit 


Name 


Access _ Description 


<9:8> 


OM 


R/W 


Operating mode - These bits determine the SGEC main operating mode. 


Value 


Meaning 


00 
01 


10 


11 


Normal operating mode. 


Internal loopback - The SGEC will loop back buffers 
from the transmit list. The data will be passed from the 
transmit logic back to the receive logic. The receive logic 
will treat the looped frame as it would any other frame, 
and subject it to the address filtering and validity check 
process. 


External loopback - The SGEC transmits normally 

and in addition, will enable its receive logic to its own 
transmissions. The receive logic will treat the looped 
frame as it would any other frame, and subject it to the 
address filtering and validity check process. 


Reserved for diagnostic 


(continued on next page) 
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Table 10-14 (Cont.) NICSR6 Bits 


Bit 


Name 


Access Description 


<7> 


<6> 


<5:4> 


<3> 


<2:1> 


<0> 


DC 


FC 


MBO 
PB 


AF 


MBO 


R/W 


Disable data chaining mode - When set, no data chaining will occur 
in reception; frames, longer than the current receive buffer, will be 
truncated. RDESO<FS,LS> will always be set. The frame length 
returned in RDESO<FL> will be the true length of the nontruncated 
frame while RDESO<BO> will indicate that the frame has been 
truncated due to buffer overflow. 


When clear, frames too long for the current receive buffer will be 
transferred to the next buffer(s) in the receive list. 


Force collision mode - This bit allows the collision logic to be tested. The 
chip must be in internal loopback mode for FC to be valid. If FC is 
set, a collision will be forced during the next transmission attempt. This 
will result in 16 transmission attempts with excessive collision reported 
in the transmit descriptor. 


Must be one. This field is reserved. Writes are ignored, read as one. 


Pass bad frames mode - When this bit is set, the SGEC will pass frames 
that have been damaged by collisions or are too short due to premature 
reception termination. Both events should have occurred within the 
collision window (64 bytes), or other errors will be reported. 


When clear, these frames will be discarded and never show up in the 
host receive buffers. 


Note 


Pass bad frames is subject the address 
filtering mode. For example, to monitor 
the network, this mode must be set 
together with the promiscuous address 
filtering mode. 


Address filtering mode - These bits define the way incoming frames will 
be address filtered: 


Value Meaning 


00 Normal - Incoming frames will be filtered according to 
the values of the <HP> and <IF> bits of the setup frame 
descriptor. 


01 Promiscuous - All incoming frames will be passed to the 
host, regardless of the <HP> bit value. 


10 All multicast - All incoming frames with multicast 
address destinations will be passed to the host. Incoming 
frames with physical address destinations will be filtered 
according to the <HP> bit value. 


11 Unused - Reserved. 


Must be one. This field is reserved. Writes are ignored, read as one. 
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Table 10-15 NICSR6 Access 
Value after RESET: 83E0F000 hex or 03E0F000 hex 


Read access rules: None 


Write access rules: 


<RE, IE, BE> Unconditional 

<BL, SE, OM> Rx and Tx processes STOPPED 

<FC> Rx and Tx processes STOPPED, Internal_Loopback 
mode 

<DC, PB, AF> Rx STOPPED 

Start_Receive <SR>=1 Rx STOPPED and NICSR3 initialized 

Start_Transmit <ST>=1 Tx STOPPED and NICSR4 initialized 

Stop_Receive <SR>=0 Rx RUNNING or SUSPENDED 

Stop_Transmit <ST>=0 Tx RUNNING or SUSPENDED 


After NICSR6 is written, the new value is readable from NICSR6. However, if 
the SGEC status does not match the related write access rules, the new mode 
setting and command do not take effect and the written information is lost, even 
if the SGEC matches the right condition later. 


10.3.8 System Base Register (NICSR7) 


This NICSR contains the physical starting address of the VAX system page table. 
This register must be loaded by host software before any address translation 
occurs so that memory will not be corrupted. 


Figure 10-8 NICSR7 Format 


3.3 2 
109 2 1 0 


MBZ System Base Address MBZ 


1/O Address: 2000 801C 


(16) 
Longword Read/Write Access 
ESB90P0058 
Table 10-16 NICSR7 Bits 
Bit Name Access Description 
<31:30> MBZ - Must be zero. Read as zero. Writes are ignored. 


(continued on next page) 
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Table 10-16 (Cont.) NICSR7 Bits 


Bit Name Access Description 


<29:00> SB R/W System base address - The physical starting 
address of the VAX system page table. Not 
used if VA (virtual addressing) is cleared in all 
descriptors. 


This register should be loaded only once 
after a reset. Subsequent modifications of 
this register at any other time may cause 
unpredictable results. 


Table 10-17 NICSR7 Access 


Value after RESET: Unpredictable 
Read access rules: None 
Write access rules: Writing once after initialization 


10.3.9 Reserved Register (NICSR8) 


This entire register is reserved. 


10.3.10 Watchdog Timers (NICSR9Q) 
The SGEC has two timers that restrict the length of time in which the chip can 


receive or transmit. 


Figure 10-9 NICSR9 Format 


3 11 
1 65 0 


RECEIVE TIME-OUT - RT TRANSMIT TIME-OUT - TT 


I/O Address: 2000 8024 
(16) 


Longword Read/Write Access 


ESB90P0059 
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Bit 


Name 


Access 


Description 


<31:16> 


<15:00> 


RT 


TT 


Receive watchdog timeout - The receive watchdog 
timer protects the host CPU against babbling 
transmitters on the network. If the receiver stays 
on for RT +16 cycles of the serial clock, the SGEC 
will cut off reception and set the NICSR5<RW> 
bit. If the timer is set to zero, it will never time 
out. 


The value of RT is an unsigned integer. With 
a 10 MHz serial clock, this provides a range 
of 72 us to 100 ms. The default value is 1250 
corresponding to 2 ms. 


The Rx watchdog timer is programmed only while 
the reception process is in the STOPPED state. 


Note ____ 


An Rx watchdog 
value between 1 and 
44 is forced to the 
minimum time_out 
value of 45 (72 ps). 


Transmit watchdog timeout - The transmit 
watchdog timer protects the network against 
babbling SGEC transmissions, on top of any 
such circuitry present in tranceivers. If the 
transmitter stays on for TT * 16 cycles of the 
serial clock, the SGEC will cut off the transmitter 
and set the NICSR5<TW> bit. 


If the timer is set to zero, it will never time out. 
The value of TT is an unsigned integer. With 

a 10 MHz serial clock, this provides a range 

of 72 us to 100 ms. The default value is 1250 
corresponding to 2 ms. 


The Tx watchdog timer is programmed only while 
the transmission process is in the STOPPED 
state. 


Note ____ 


A Tx watchdog value 
between 1 and 44 

is forced to the 
minimum time_out 
value of 45 (72 ps). 
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Table 10-19 NICSR9 Access 
Value after RESET: 00000000 hex 


Read access rules: None 


Write access rules: 
Rx watchdog timer Rx process STOPPED 
Tx watchdog timer Tx process STOPPED 


These watchdog timers are enabled by default. These timers will assume the 
default values after hardware or software resets. 


10.3.11 Revision Number and Missed Frame Count (NICSR10) 


This register contains a missed frame counter and SGEC identification 
information. 


Figure 10-10 Revision Number and Missed Frame Count (VIRTUAL NICSR10) 
3 211111 
1 098765 ) 


I/O Address: 2000 802C 
(16) 


Longword Read Only Access 


ESB90P0060 
Table 10-20 NICSR10 Bits 
Bit Name Access Description 
<31:21> MBZ - Must be zero. Read as zero. Writes are ignored. 
<20:16> RN R Chip revision number - This stores the revision 
number for this particular SGEC. 
<15:00> MFC R Missed frame count - Counter for the number of 


frames that were discarded and lost because host 
receive buffers were unavailable. The counter is 
cleared when read by the host. 


Table 10-21 NICSR10 Access 


Value after RESET: 00030000 hex 
Read access rules: Missed_frame counter cleared by read 
Write access rules: Not applicable 
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10.3.12 Boot Message (NICSR11, 12, 13) 
These registers contain the boot message VERIFICATION and PROCESSOR 


fields. The format is shown in Figure 10—11 and the bit descriptions are in 
Table 10-22. 
Figure 10-11 Boot Message 


3322 
1098 


NP 


22 2222 11 
6543210 109876543210 
20000802C 
VERIFICATION VRF <31:00> 16 
3322222222221111114%1411~41 
10987654321098765432109876543210 
20008030 
VERIFICATION VRF <63:32> 16 


32222 2 111111141 1 
09876 3 98765432109876543210 


0/0/0|0|0|0|0|0|0}0}0/0|0  oj0j0 | 0|0|0|0/0|0|0/0) PROCESSOR PRC | NICSR13 
20008034 


3 222222 1 
1 543210 1 


16 

Longword Read/Write Access 

ESB90P0061 
Table 10-22 NICSR11,12,13 Bits 
Bit Name Access Description 
NICSR11 <31:00> VRF<31:00> R/W Boot message verification field <31:00> 
NICSR12 <31:00> VRF<63:32> R/W Boot message verification field <63:32> 
NICSR13 <07:00> PRC R/W Boot message processor field 

Note 


The least significant bit of the verification field (VRF<0>) corresponds to 
the first incoming bit of the verification field in the serial boot message. 


Table 10-23 NICSR11,12,13 Access 


Value after RESET: 00000000 hex for each of NICSR11,NICSR12,NICSR13 
Read access rules: None 
Write access rules: Boot message disabled (<NICSR6<BE> = 0) 
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10.3.13 Diagnostic Registers (NICSR14, 15) 
These registers are reserved for diagnostic features. 

10.3.13.1 Diagnostic Breakpoint Address Register (NICSR14) 
This register is virtual CSR. It contains the breakpoint address that will cause 
the internal CPU to jump to a patch address. Figure 10-12 shows the format 


of the register. Table 10—24 lists the bits and descriptions. This register can be 
loaded only in diagnostic mode (NICSR6 <OM>=<11>). 


Figure 10-12 NICSR14 Format 


111414411141 1 
98765432 09876543210 


B CODE RESTART ADDRESS BREAKPOINT ADDRESS 
E (CRA) (BPA) 


33222222222 
10987654321 


ESB90P0062 
Table 10-24 NICSR14 Bits 
Bit Name Type Description 
<31> BE R/W When set, breakpoint enabled. 
<30:16> CRA R/W Code restart address - The first address in the 


internal RAM where the internal processor will 
jump after a breakpoint occurred. 


<15:0> BPA R/W Breakpoint address - The internal processor 
address at which the program will halt and jump 
to the RAM loaded code. 


Note 


This register, in conjunction with the diagnostic descriptors, allows 
software patches. 


Table 10-25 NICSR14 Access 


Value after RESET: 0000000046 

Read access rules: None 

Write access rules: Diagnostic mode 

Violation: Addressing NICSR14 while NICSR5<DN> is deasserted 


10.3.13.2 Monitor Command Register (NICSR15) 
This register is a physical CSR. It contains the bits that will select the internal 
test block operation mode. Figure 10-13 shows the format of the register. 
Table 10-26 lists the bits and descriptions. 
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Figure 10-13 NICSR15 Format 


332222222222 i%11d41d44 31313 «1~«4'4 
1098 7645432%1092872C654 321098765 43210 
ADDRESS/DATA S}QAD]B MBZ 
T Ss 

ESB90P0063 
Table 10-26 NICSR15 Bits 
Bit Name Type Description 
<31:16> ADDR/DATA R/W Before the "Examine" cycle, it points to the 


location to be read. Three cycles after the 
assertion of <ST>, it contains the read data. 


<15> ST W Start read - When set, starts the "Examine" cycle: 
the data addressed by CSR<31:16> is fetched 
and stored into the same register field. Reset by 
hardware at the end of operation. 


<14:13> QAD W Quad selects bits - These bits define the specific 
four bits of the internal Data_bus or Address_ 
bus, which are monitored on the external test 
pins BM_L/TEST<3:0>. Meaningful only in test 
mode (TSM=1). 


The 2-bit code is interpreted as follows. 


QAD Data Address 

00 <03:00> <03:00> 

01 <07:04> <07:04> 

10 <11:08> <11:08> 

11 <15:12> 0, IOP_WR_L,<13:12> 
<12> BS W Bus select - When reset, the internal Data_bus 


is monitored on the external test pins BM_L 
/TEST<3:0>. When set, the monitoring is applied 
on the internal Address_bus. Meaningful only in 
test mode (TSM=1). 


<11:0> MBZ a Must be zero. 


Table 10-27 NICSR15 Access 


Value after RESET: OO000F FF 1¢ 

Read access rules: None 

Write access rules: Reserved for DEBUGGING 

Violation: Setting <ST> with "random" SGEC internal address 
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10.3.14 Descriptors and Buffers Format 


The SGEC transfers frame data to and from receive and transmit buffers in host 
memory. These buffers are pointed to by descriptors, which are also resident in 
host memory. 


There are two descriptor lists: one for receive and one for transmit. The starting 
address of each list is written into NICSRs 3 and 4, respectively. A descriptor list 
is a forward-linked (either implicitly or explicitly) list of descriptors, the last of 
which may point back to the first entry, thus creating a ring structure. Explicit 
chaining of descriptors, through setting xDES1<CA>, is called descriptor 
chaining. The descriptor lists reside in VAX physical memory address space. 


Note 


The SGEC first reads the descriptors, ignoring all unused bits regardless 
of their state. The only word the SGEC writes back is the first word 
(xDESO) of each descriptor. Unused bits in xDESO will be written as “0.” 
Unused bits in xDES1 - xDES3 may be used by the port driver and the 
SGEC will never disturb them. 


A data buffer can contain an entire frame or part of a frame, but it cannot contain 
more than a single frame. Buffers contain only data; buffer status is contained 
in the descriptor. The term data chaining is used to refer to frames spanning 
multiple data buffers. Data chaining can be enabled or disabled, in reception, 
through NICSR6<DC>. Data buffers reside in VAX memory space, either physical 
or virtual. 


Note 


The virtual-to-physical address translation is based on the assumption 
that PTEs are locked in the host memory during the time the SGEC owns 
the related buffer. 


Note 


For best performance in virtual addressing mode, PPTE vectors must not 
cross a page of the PPTE table. 


10.3.15 Receive Descriptors 


The receive descriptor format is shown in Figure 10—14, and described in the 
following paragraphs. 
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Figure 10-14 Receive Descriptor Format 


B28) 123 in 2. AO: 2 VB? 2 ED Duce A NS Ae Ae AT Tee eed’ A 

1° 0 9 8 ¥ 6 & 4 3 2 71:09 8 F¥ 6 56 43 2 7109 8 7 6 & 43 2 1 90 

oO E;/L] DT |RIB/]FIJLITIC]FJO;T]D]C]O RDESO 
WwW Frame Length SJE FIO;|S|]S|/L]S]T N|IBJE]F 


Cc|V RDES1 
AJA 
RDES2 
Buffer Size Page Offset 
RDES3 
BUFFER SVAPTE/Physical Address 


0 - SGEC writes as ZERO 
u — Ignored by the SGEC on read, never written 


ESB90P0064 


10.3.15.1 RDESO Word 
RDESO word contains received frame status, length, and descriptor ownership 
information. 


Table 10-28 RDESO Bits 
Bit Name Description 


<31> OW Own bit - When set, indicates the descriptor is owned by the SGEC. 
When cleared, indicates the descriptor is owned by the host. The 
SGEC clears this bit upon completing processing of the descriptor 
and its associated buffer. 


<30:16> FL Frame length - The length in bytes of the received frame. 
Meaningless if RDESO<LE> is set. 

<15> ES Error summary - The logical “OR” of RDESO bits OF, CE, TN, CS, 
TL, LE, and RF. 

<14> LE Length error - When set, indicates a frame truncation caused by one 


of the following: 


e The frame segment does not fit within the current buffer and the 
SGEC does not own the next descriptor. The frame is truncated. 


e The receive watchdog timer expired. NICSR5<RW> is also set. 


(continued on next page) 
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Table 10-28 (Cont.) RDESO Bits 


Bit Name Description 
<13:12> DT Data type - Indicates the type of frame the buffer contains, according 
to the following table: 
Value Meaning 
00 Serial received frame 
01 Internally looped back frame 
10 Externally looped back frame, serial received frame * 
<1l> RF Runt frame - When set, indicates this frame was damaged by a 


collision or premature termination before the collision window 
had passed. Runt frames will be passed on to the host only if 
(NICSR6<PB>) is set. Meaningless if RDESO<OF> is set. 


<10> BO Buffer overflow - When set, indicates that the frame has been 
truncated due to a buffer too small to fit the frame size. This bit may 
be set only if data chaining is disabled (NICSR6<DC> = 1). 


<09> FS First segment - When set, indicates this buffer contains the first 
segment of a frame. 


<08> LS Last segment - When set, indicates this buffer contains the last 
segment of a frame and status information is valid. 


<07> TL Frame too long - When set, indicates the frame length exceeds the 
maximum Ethernet specified size of 1518 bytes. 


Note 


Frame too long is only a frame length 
indication and does not cause any 
frame truncation. 


<06> CS Collision seen - When set, indicates the frame was damaged by a 
collision that occurred after the 64 bytes following the SFD. 


<05> FT Frame type - When set, indicates the frame is an Ethernet type 
frame (Frame Length_Field > 1500). When clear, indicates the frame 
is an IEEE 802.3 type frame. Meaningless for runt frames < 14 


bytes. 
<04> 0 Zero. SGEC writes as zero. 
<03> TN Translation not valid - When set, indicates that a translation error 


occurred when the SGEC was translating a VAX virtual buffer 
address. It will only set if RDES1<VA> was set. The reception 
process remains in the RUNNING state and attempts to acquire the 
next descriptor. 


'The SGEC does not differentiate between the loopback and the serial received frames. Therefore, this information is 
global and reflects only NICSR6<OM>. 


(continued on next page) 


10-30 Network Interface 


Table 10-28 (Cont.) RDESO Bits 


Network Interface 
10.3 Programming the SGEC 


Bit 


Name 


Description 


<02> 


<01> 


<00> 


DB 


CE 


OF 


Dribbling bits - When set, indicates the frame contained a noninteger 
multiple of eight bits. This error will be reported only if the number 

of dribbling bits in the last byte is greater than two. Meaningless if 

RDESO<CS> or RDESO<RF> is set. 


The CRC check is performed independent of this error; however, 
only whole bytes are run through the CRC logic. Consequently, 
received frames with up to six dribbling bits will have this bit 
set, but if <CE> (or another error indicator) is not set, these 
frames should be considered valid: 


CE DB Error 


None 
None 
CRC error 


0 
0 
1 
1 Alignment error 


0 
1 
0 
1 


CRC Error - When set, indicates that a CRC error has occurred on 
the received frame. 


Overflow - When set, indicates received data in this descriptor’s 
buffer was corrupted due to internal FIFO overflow. This will 
generally occur if SGEC DMA requests are not granted before the 
internal receive FIFO fills up. 


10.3.15.2 RDES1 Word 


Table 10-29 RDES1 Bits 


Bit 


Name 


Descriptor 


<31> 


CA 


Chain address - When set, RDES3 is interpreted as another 
descriptor’s VAX physical address. This allows the SGEC to process 
multiple, non-contiguous descriptor lists and explicitly "chain" the 
lists. Note that contiguous descriptors are implicitly chained. 


In contrast to what is done for an Rx buffer descriptor, the SGEC 
clears neither the ownership bit RDESO<OW> nor one of the other 
bits of RDESO of the chain descriptor after processing. 


To protect against infinite loop, a chain descriptor pointing back to 
itself, is seen as owned by the host, regardless of the ownership bit 
state. 


(continued on next page) 
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Table 10-29 (Cont.) RDES1 Bits 


Bit 


Name 


Descriptor 


<30> 


<29> 


<28:0> 


VA 


VT 


Virtual addressing - When set, RDES3 is interpreted as a virtual 
address. The type of virtual address translation is determined by the 
RDES1<VT> bit. The SGEC uses RDES3 and RDES2<Page Offset> 
to perform a VAX virtual address translation process to obtain the 
physical address of the buffer. When clear, RDES3 is interpreted as 
the actual physical address of the buffer: 


VA VT Addressing Mode 


0 x Physical 
1 0 Virtual - SVAPTE 
1 1 Virtual - PAPTE 


Virtual type - In case of virtual addressing (RDES1<VA> = 1), 
indicates the type of virtual address translation. When set, the 
buffer address RDESS3 is interpreted as an SVAPTE (system virtual 
address of the page table entry). When clear, the buffer address is 
interpreted as a PAPTE (physical address of the page table entry). 
Meaningful only if RDES1<VA> is set. 


Unused. Ignored by the SGEC on reads. Never written. 


10.3.15.3 


Table 10-30 RDES2 Bits 


RDES2 Word 


Bit Name Descriptor 
<31> u Unused. Ignored by the SGEC on reads. Never written. 
<30:16> BS Buffer size - The size, in bytes, of the data buffer. 
Note 
Receive buffer size must be an even 
number of bytes. 
<15:9> u Unused. Ignored by the SGEC on reads. Never written. 
<08:00> PO Page offset - The byte offset of the buffer within the page. Only 
meaningful if RDES1<VA> is set. 
Note 
Receive buffers must be word-aligned. 
10.3.15.4 RDES3 Word 
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Bit Name 


Descriptor 


<31:00> SV/PV/PA 


SVAPTE/PAPTE/Physical address - When RDES1<VA> is set, RDES3 
is interpreted as the address of the page table entry and is used in 
the virtual address translation process. The type of the address, 
system virtual address (SVAPTE) or physical address (PAPTE), is 
determined by RDES1<VT>. When RDES1<VA> is clear, RDES3 is 
interpreted as the physical address of the buffer. When RDES1<CA> 
is set, RDES3 is interpreted as the VAX physical address of another 


descriptor. 


Note 


Receive buffers must be word-aligned. 


10.3.15.5 Receive Descriptor Status Validity 
The following table summarizes the validity of the receive descriptor status bits 


regarding the reception completion status: 


Table 10-32 Receive Descriptor Status Validity 


Reception Rx Status Report 

Status RF TL CS FT DB CE (ES,LE,BO,DT,FS,LS,FL,TN,OF ) 
Overflow X V X V X X Vv 

Collision after 512 bits V VV VX X Vv 

Runt frame V VV VX X Vv 

Runt frame < 14 bytes V VV XK X X Vv 

Watchdog timeout VV xX V X X Vv 

V - Valid 


X - Meaningless 


10.3.16 Transmit Descriptors 


The transmit descriptor format is shown in Figure 10-15, and described in the 
following paragraphs. 
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Figure 10-15 Transmit Descriptor Format 


9 8 7 6 5 43 2 1 «0 


Coll. a D TDESO 
Count N E 
DT |AJF TDES1 
i c|s C u 
TDES2 
Buffer Size Page Offset 
TDES3 
ufdu BUFFER SVAPTE/Physical Address 


0 - SGEC writes as "0" 
u — Ignored by the SGEC on read, never written 


ESB90P0065 


10.3.16.1 TDESO Word 


TDESO word contains transmitted frame status and descriptor ownership 
information. 


Table 10-33 TDESO Bits 
Bit Name _ Description 


<31> OW Own bit - When set, indicates the descriptor is owned by the SGEC. When cleared, 
indicates the descriptor is owned by the host. The SGEC clears this bit upon completing 
processing of the descriptor and its associated buffer. 


<29:16> TDR _ Time domain reflectometer - This is a count of bit time and is useful for locating a fault 
on the cable using the velocity of propagation on the cable. Only valid if TDESO<EC> is 
also set. Two excessive collisions in a row and with the same or similar (within 20) TDR 
values indicate a possible cable open. 


<15> ES Error summary - The logical “OR” of UF, TN, EC, LC, NC, LO, LE, and TO. 


<14> TO Transmit watchdog timeout - When set, indicates the transmit watchdog timer has timed 
out, indicating the SGEC transmitter was babbling. The interrupt NICSR5<TW> is set 
and the transmission process is aborted and placed in the STOPPED state. 


<13> MBZ Must be zero. SGEC writes as zero. 
<12> LE Length error - When set, indicates one of the following: 


¢ Descriptor unavailable (owned by the host) in the middle of data chained descriptors. 
¢ Zero length buffer in the middle of data chained descriptors. 


e Setup or diagnostic descriptors (Data type TDES1<DT> <> 0) in the middle of data 
chained descriptors. 


¢ Incorrect order of first_segment TDES1<FS> and last_segment TDES1<LS> 
descriptors in the descriptor list. 


¢ The Transmission process enters the SUSPENDED state and sets NICSR5<TI>. 


(continued on next page) 
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Table 10-33 (Cont.) TDESO Bits 


Bit 


Name_ Description 


<1l> 


<10> 


<09> 


<08> 


<07> 


<06:03> 


<02> 


<01> 


<00> 


LO 


NC 


LC 


EC 


HF 


CC 


TN 


UF 


DE 


Loss of carrier - When set, indicates loss of carrier during transmission (possible short 
circuit in the Ethernet cable). 


Meaningless in internal loopback mode (NICSR5<OM>=1). 


No carrier - When set, indicates the carrier signal from the transceiver was not present 
during transmission (possible problem in the transceiver or transceiver cable). 


Meaningless in internal loopback mode (NICSR5<OM>=1). 


Late collision - When set, indicates frame transmission was aborted due to a late 
collision. Meaningless if TDESO<UF>. 


Excessive collisions - When set, indicates that the transmission was aborted because 16 
successive collisions occurred while attempting to transmit the current frame. 


Heartbeat fail - When set, indicates heartbeat collision check failure (the transceiver 
failed to return a collision pulse as a check after the transmission). Some tranceivers do 
not generate heartbeat, and will always have this bit set. If the transceiver does support 
it, it indicates transceiver failure. Meaningless if TDESO<UF>. 


Collision count - A 4-bit counter indicating the number of collisions that occurred before 
the transmission attempt succeeded or failed. Meaningless when TDESO<EC> is also 
set. 


Translation not valid - When set, indicates that a translation error occurred when the 
SGEC was translating a VAX virtual buffer address. It may only set if TDES1<VA> was 
set. The transmission process enters the SUSPENDED state and sets NICSR5<TI>. 


Underflow error - When set, indicates that the transmitter has truncated a message due 
to data late from memory. UF indicates that the SGEC encountered an empty transmit 
FIFO while in the midst of transmitting a frame. The transmission process enters the 
SUSPENDED state and sets NICSR5<TI>. 


Deferred - When set, indicates that the SGEC had to defer while trying to transmit a 
frame. This condition occurs if the channel is busy when the SGEC is ready to transmit. 


10.3.16.2 TDES1 Word 


Table 10-34 TDES1 Bits 


Bit 


Name Descriptor 


<31> 


CA Chain address - When set, TDES3 is interpreted as another 
descriptor’s VAX physical address. This allows the SGEC to process 
multiple, non-contiguous descriptor lists and explicitly "chain" the 
lists. Note that contiguous descriptors are implicitly chained. 


In contrast to what is done for an Rx buffer descriptor, the SGEC 
clears neither the ownership bit TDESO<OW> or one of the other 
bits of TDESO of the chain descriptor after processing. 


To protect against infinite loop, a chain descriptor pointing back to 
itself, is seen as owned by the host, regardless of the ownership bit 
state. 


(continued on next page) 
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Table 10-34 (Cont.) TDES1 Bits 


Bit Name 


Descriptor 


<30> VA 


<29:28> DT 


<27> AC 


<26> FS 


<25> LS 


<24> IC 


<23> VT 


<22:0> u 


Virtual addressing - When set, TDES3 is interpreted as a virtual 
address. The type of virtual address translation is determined by the 
TDES1<VT> bit. The SGEC uses TDES3 and TDES2<Page Offset> 
to perform a VAX virtual address translation process to obtain the 
physical address of the buffer. When clear, TDES3 is interpreted as 
the actual physical address of the buffer: 


VA VT Addressing Mode 


0 x Physical 
1 0 Virtual - SVAPTE 
1 1 Virtual - PAPTE 


Data type - Indicates the type of data the buffer contains, according 
to the following table: 


Value Meaning 


00 Normal transmit frame data 
10 Setup frame - Explained in Section 10.3.17. 
11 Diagnostic frame 


Add CRC disable - When set, the SGEC will not append the CRC to 
the end of the transmitted frame. To take effect, this bit must be set 
in the descriptor where FS is set. 


Note 


If the transmitted frame is shorter 
than 64 bytes, the SGEC will add the 
padding field and the CRC regardless 
of the <AC> flag. 


First segment - When set, indicates the buffer contains the first 
segment of a frame. 


Last segment - When set, indicates the buffer contains the last 
segment of a frame. 


Interrupt on completion - When set, the SGEC will set NICSR5<TI> 
after this frame has been transmitted. To take effect, this bit must 
be set in the descriptor where LS is set. 


Virtual type - In case of virtual addressing (TDES1<VA> = 1), 
indicates the type of virtual address translation. When set, the 
buffer address TDESS is interpreted as an SVAPTE (system virtual 
address of the page table entry). When clear, the buffer address is 
interpreted as a PAPTE (physical address of the page table entry). 
Meaningful only if TDES1<VA> is set. 


Unused. Ignored by the SGEC on reads. Never written. 
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Bit Name Descriptor 
<31> u Unused. Ignored by the SGEC on reads. Never written. 
<30:16> BS Buffer size - The size, in bytes, of the data buffer. If this field is 
0, the SGEC will skip over this buffer and ignore it. The frame 
size is the sum of all BS fields of the frame segments (between and 
including the descriptors having TDES1<FS> and TDES1<LS> set.) 
Note 
If the port driver wishes to suppress 
transmission of a frame, this field 
must be set to 0 in all descriptors 
comprising the frame and prior to the 
SGEC acquiring them. If this rule is 
not adhered to, corrupted frames might 
be transmitted. 
<08:00> PO Page offset - The byte offset of the buffer within the page. Only 


meaningful if TDES1<VA> is set. 


Note 


Transmit buffers may start on 
arbitrary byte boundaries. 


10.3.16.4 TDES3 Word 


Table 10-36 TDES3 Bits 


Bit Name 


Descriptor 


<31:00> SV/PV/PA 


SVAPTE/PAPTE/Physical address - When TDES1<VA> is set, TDES3 
is interpreted as the address of the page table entry and is used 

in the virtual address translation process. The type of the address 
system virtual address (SVAPTE) or physical address (PAPTE), is 
determined by TDES1<VT>. When TDES1<VA> is clear, TDES3 is 
interpreted as the physical address of the buffer. When TDES1<CA> 
is set, TDES3 is interpreted as the VAX physical address of another 
descriptor. 


Note 


Transmit buffers may start on 
arbitrary byte boundaries. 
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10.3.16.5 Transmit Descriptor Status Validity 


Table 10-37 summarizes the validity of the transmit descriptor status bits 
regarding the transmission completion status: 


Table 10-37 Transmit Descriptor Status Validity 


Transmission 
Status 


Tx Status Report 
LO NC LC EC HF CC (ES,TO,LE,TN,UF,DE) 


Underflow 


Excessive collisions VV 
Watchdog timeout xX V 
xX XxX 


Internal loopback 


Xx X V V X V V 
VV VX V 
X X X \V V 
Vv x Vv V 


V - Valid 
X - Meaningless 


10.3.17 Setup Frame 


A setup frame defines SGEC Ethernet destination addresses. These addresses 
will be used to filter all incoming frames. The setup frame is never transmitted 
over the Ethernet, nor looped back to the receive list. While the setup frame is 
being processed, the receiver logic will temporarily disengage from the Ethernet 
wire. The setup frame size is always 128 bytes and must be wholly contained in 
a single transmit buffer. There are two types of setup frames: 


1. Perfect filtering addresses (16) list 
2. Imperfect filtering hash bucket (512) heads + one physical address 


10.3.17.1 First Setup Frame 


A setup frame must be queued (placed in the transmit list with SGEC 
ownership) to the SGEC before the reception process is started, except for when 
the SGEC operates in promiscuous reception mode. 


Note 


The self-test completes with the SGEC address filtering table fully set to 
"0." A reception process started without loading a setup frame will reject 
all the incoming frames except those with a destination physical address 
= 000000h. 


10.3.17.2 Subsequent Setup Frame 


Subsequent setup frames may be queued to the SGEC regardless of the reception 
process state. The only requirement for the setup frame to be processed is that 
the transmission process be in the RUNNING state. The setup frame will be 
processed after all preceding frames have been transmitted and after the current 
frame reception, if any, is completed. 


The setup frame does not affect the reception process state but during the setup 
frame processing, the SGEC is disengaged from the Ethernet wire. 
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10.3.17.3 Setup Frame Descriptor 


The setup frame descriptor format is shown in Figure 10-16, and described in the 
following paragraphs. 


Figure 10-16 Setup Frame Descriptor Format 


B28. 72. BD Dy Di BE DB OE 8. pete <A a EASA) A PA 
109 8765 43 2109 8 765 43 2102908726 5 43 21 0 
SDESO 
SDES1 
SDES2 
Buffer Size 
SDES3 
Setup Buffer Physical Address 
0 - SGEC writes as "0" 
u — Ignored by the SGEC on read, never written 
ESB90P0066 
Table 10-38 Setup Frame Descriptor Bits 
Word Bit Name Description 
SDESO <13> SE Setup error - When set, indicates the setup frame 
buffer size is not 128 bytes. 
<15> ES Error summary - Set when SE is set. 
<31> OW Own bit - When set, indicates the descriptor is 


owned by the SGEC. When cleared, indicates 
the descriptor is owned by the host. The SGEC 
clears this bit upon completing processing of the 
descriptor and its associated buffer. 


SDES1 <24> IC Interrupt on completion - When set, the SGEC 
will set NICSR5<TI> after this setup frame has 
been processed. 


<25> HP Hash/perfect filtering mode - When set, the 
SGEC will interpret the setup frame as a hash 
table, and do an imperfect address filtering. The 
imperfect mode is useful when there are more 
than 16 multicast addresses to listen to. 


When clear, the SGEC will do a perfect address 
filter of incoming frames according to the 
addresses specified in the setup frame. 


(continued on next page) 
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Table 10-38 (Cont.) Setup Frame Descriptor Bits 


Word 


Bit Name Description 


SDES2 
SDES3 


<26> IF Inverse filtering - When set, the SGEC will do 
an inverse filtering; the SGEC will receive the 
incoming frames with destination address not 
matching the perfect addresses, and will reject 
the frames with destination address matching 
one of the perfect addresses. 


Meaningful only for Perfect_filtering 
(SDES1<HP>=0), while Promiscuous and 
All_Multicast modes are not selected 
(NICSR6<AF>=0). 


<29:28> DT Data type - Must be 2 to indicate setup frame. 
<30:16> BS Buffer size - Must be 128. 


<29:1> PA Physical address - Physical address of setup 
buffer. 


Note 


Setup buffer must be 
word-aligned. 


10.3.17.4 Perfect Filtering Setup Frame Buffer 


This section describes how the SGEC interprets a setup frame buffer when 
SDES1<HP> is clear. 


The SGEC can store 16 (full 48 bits Ethernet) destination addresses. It will 
compare the addresses of any incoming frame to these, and regarding the status 
of Inverse_Filtering flag SDES1<IF>, will reject the following: 


e Those that do not match, if SDES1<IF> = 0 
¢ Those that match, if SDES1<IF> = 1 


The setup frame must always supply all 16 addresses. Any mix of physical and 
multicast addresses can be used. Unused addresses should be duplicates of one of 
the valid addresses. The addresses are formatted as shown in Figure 10-17. 
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Figure 10-17 Perfect Filtering Setup Frame Buffer Format 


Bytes <3:0> 


<123:120> 
<127:124> | XXXXXXXXXXXXXXX| 


31 16 15 


0 bit 


PERFECT ADDRESS_00 
<7:4> | XXXXXXXXXXXXXXX 


a 


PERFECT ADDRESS_01 


XXXXXXXXXXXXXXX 


PERFECT ADDRESS_02 


XXXXXXXXXXXXXXX 


PERFECT ADDRESS_03 


XXXXXXXXXXXXXXX 


PERFECT ADDRESS_04 


XXXXXXXXXXXXXXX 


PERFECT ADDRESS_05 


PERFECT ADDRESS_13 


XXXXXXXXXXXXXXX 


PERFECT ADDRESS_14 


XXXXXXXXXXXXXXX 


PERFECT ADDRESS_15 


XXXXXxX = don’t care 


Physical/Multicast bit 


ESB90P0067 
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The low-order bit of the low-order bytes is the address’s multicast bit. 
Example 10-1 illustrates a perfect filtering setup buffer (fragment). 


Example 10-1 Perfect Filtering Buffer 
Ethernet addresses to be filtered: 
@ 8-09-65-12-34-76 
09-BC-87-DE-03-15 


Setup frame buffer fragment: 
@ 126509a8 
00007634 
DE87BC09 
00001503 


@ Two Ethernet addresses written according to the DEC STD 134 specification 
for address display. 


© Those two addresses as they would appear in the buffer. 


10.3.17.5 Imperfect Filtering Setup Frame Buffer 


This section describes how the SGEC interprets a setup frame buffer when 
SDES1<HP> is set. 


The SGEC can store 512 bits, serving as hash bucket heads, and one physical 
48-bit Ethernet address. Incoming frames with multicast destination addresses 
will be subjected to the imperfect filtering. Frames with physical destination 
addresses will be checked against the single physical address. 


For any incoming frame with a multicast destination address, the SGEC 
applies the standard Ethernet CRC function to the first six bytes containing 
the destination address. It then uses the most significant nine bits of the result 
as a bit index into the table. If the indexed bit is set, the frame is accepted. If it 
is cleared, the frame is rejected. 


This filtering mode is called imperfect because multicast frames not addressed to 
this station may slip through; however, it will still cut down the number of frames 
with which the host will be presented. 


The format for the hash table and the physical address is shown in Figure 10-18. 
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Figure 10-18 Imperfect Filtering Setup Frame Format 


bytes <3:0> 
<7:4> 


<63:60> 


<67:64> 
<71:68> 


<75:72> 


<127:120> 


31 16 15 


0 bit 


HASH_FILTER_00 
HASH_FILTER_01 


HASH_FILTER_14 
HASH_FILTER_15 


PHYSICAL ADDRESS 
XXXXXXXXXXXXXXXX 


XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXK 
XXXXXXXXXXXXXXXXXXXXXXXXXXXXKXXXK 
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXK 
XXXXXXXXXXXXXXXXXXXXXXXXXXXXKXXXK 
XXXXXXXXXXXXXXXXXXXXXXXXXXXXKXXXK 
XXXXXXXXXXXXXXXXXXXXXXXXXXXXKXXXK 
XXXXXXXXXXXXXXXXXXXXXXXXXXXXKXXXK 
XXXXXXXXXXXXXXXXXXXXXXXXXXXXKXXXK 
XXXXXXXXXXXXXXXXXXXXXXXXXXXXKXXXK 
XXXXXXXXXXXXXXXXXXXXXXXXXXXXKXXXK 
XXXXXXXXXXXXXXXXXXXXXXXXXXXXKXXXK 
XXXXXXXXXXXXXXXXXXXXXXXXXXXXKXXXK 
XXXXXXXXXXXXXXXXXXXXXXXXXKXXXKXXXK 
XXXXXXXXXXXXXXXXXXXXXXXXXXXXKXXXK 


XXXXXX = don’t care 


Physical/Multicast bit 


ESB90P0068 


Bits are sequentially numbered from right to left and down the table. For 
example, if CRC (destination address)<8:0> = 33, the SGEC will examine bit 


#1 in the second longword. 


Example 10—2 illustrates an imperfect filtering setup frame buffer. 


Example 10-2 Imperfect Filtering Buffer 
Ethernet addresses to be filtered: 


25-00-25-00-27-00 
A3-C5-62-3F-25-87 
D9-C2-C0-99-0B-82 
7D-48-4D-FD-CC-0A 
E7-C1-96-36-89-DD 
61-CC-28-55-D3-C7 
6B-46-0A-55-2D-7E 


@ = 28-12-34-35-76-08 


Setup frame buffer: 
00000000 
10000000 
00000000 
00000000 
00000000 
40000000 
00000080 
00100000 
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Network Interface 10-43 


Network Interface 
10.3 Programming the SGEC 


Example 10-2 (Cont.) Imperfect Filtering Buffer 


00000000 
10000000 
00000000 
00000000 
00000000 
00010000 
00000000 
00400000 

@ 3534128 
00000876 


Ethernet multicast addresses written according to the DEC STD 134 
specification for address display. 


An Ethernet physical address. 


The first part of an imperfect filter setup frame buffer with set bits for the @ 
multicast addresses. 


The second part of the buffer with the @ physical address. 


6 80 6 


Example 10-3 shows a C program to compute the hash bucket heads and create 
the resulting setup frame buffer. 


Example 10-3 Imperfect Filtering Setup Frame Buffer Creation C Program 
#include <stdio> 


unsigned int imperfect_setup_frame[128/4], /* The setup buffer - 128 */ 


/* bytes */ 
address [2], 
crc[33]; /* CRC residue vector */ 


main () 


{ 
int i, hash; 
je ei). 
/* This program accepts 48 bits Ethernet addresses and builds a Setup frame */ 
/* buffer for imperfect filtering. */ 
/* */ 
/* Addresses must be entered in hexadecimal. The multicast bit is the least */ 
/* significant bit of the least significant digit of the first 32 bits. Af 
/* Non-multicast addresses are ignored. */ 
/* */ 
/* Input is terminated by keying CIRL/Z after which the program prints out */ 
/* the buffer. ef 
[* x] 
main_loop: 
/* Prompt user for the Ethernet address af 


printf("\n\n Enter the first 32 bits (HEX) - "); 
if (scanf("%x", &address[0]) == EOF) 


printf ("\n\n Imperfect Setup buffer printout\n"); 
for (i=0; i < 128/4; i++) 

printf ("%08X\n", imperfect_setup_frame[i]); 
exit (1); 

} 


(continued on next page) 
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Example 10-3 (Cont.) Imperfect Filtering Setup Frame Buffer Creation C 
Program 
printf("\n Enter the remaining 16 bits (HEX) - "); 
scanf ("%Sx", &address[1]); 


/* Ignore non multicast addresses a 
if ((address[0] & 1) == 0) 
goto main_loop; 


/* Compute the hash function */ 
hash = address_crc(address[0],address[1]); 


/* Set the appropriate bit in the Setup buffer */ 
imperfect_setup_frame[hash/32] = 
imperfect_setup_frame[hash/32] | 1 << hash%32; 


goto main_loop; 


} 


int address_crc( unsigned int lsb32 , unsigned int msbl6) 
{ 
int j,hash = 0; 


/* Set CRC to all 1's */ 
for (j=0; 3 < 33; jtt) 
cerce[j] = 1; 
/* Compute the address CRC by running the CRC 48 steps */ 


for (j=0; j < 32; jtt) 
nextstate(lsb32 & 1<<j ? 1: 0); 

for (j=0;  j < 16; j++) 
nextstate(msb16 & 1<<j ? 1: 0); 


/* Extract 9 most significant bits from the CRC residue +1. 


for (j=24; 4 < 33; jtt) 
hash = hash<<1 | crc[j]; 


return hash; 


nextstate (dat) 


int dat; 

{ 
int i,mean; 
mean = crc[32] * dat; 
for (1=32;1>=2;1--) crce[i]J=crce[i-1]; 
erc[27] = crce[27] * mean; 
erc[24] = crce[24] * mean; 
cerc[23] = crce[23] * mean; 
crc[17] = crce[17] * mean; 
crc[13] = crce[13] * mean; 
erc[12] = crce[12] * mean; 
erc[11] = crce[1l] * mean; 
crc[9] = crc[9] * mean; 
crc[8] = crc[8] * mean; 
crc[6] = crc[6] * mean; 
erc[5] = crce[5] * mean; 
crc[3] = crc[3] * mean; 
crce[2] = crc[2] * mean; 
crc[1] = mean; 
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10.3.18 SGEC Operation 


10.3.18.1 Hardware and Software Reset 


The SGEC responds to two types of reset commands: a hardware reset 
through the RESET_L pin, and a software reset command triggered by setting 
NICSR6<RE>. In both cases, the SGEC aborts all ongoing processing and 
starts the reset sequence. The SGEC restarts and reinitializes all internal states 
and registers. No internal states are retained, no descriptors are owned, and all 
the host visible registers are set to “0,” except where otherwise noted. 


Note 


The SGEC does not explicitly disown any owned descriptor; therefore, 
descriptors’ owned bits might be left in a state indicating SGEC 
ownership. 


Table 10—39 indicates the NICSR fields that are not set to “O” after reset: 


Table 10-39 NICSR Fields Not Reset to Zero 


Field Value 

NICSR3 Unpredictable 

NICSR4 Unpredictable 

NICSR5<DN> 1 

NICSR6<BL> 1 

NICSR6<RE> Unpredictable after hardware reset 
1 after software reset 

NICSR7 Unpredictable 

NICSR9 RT = TT = 1250 


After the reset sequence completes, the SGEC executes the self-test procedure to 
do basic checking. 


If the self-test completes successfully, the SGEC initializes the SGEC, and sets 
the initialization done flag NICSR5<ID>. 


At the first failure detected in one of the basic tests executed in the self_test 
routine, the test is aborted and the self_test failure NICSR5<SF> is set together 
with the self_test error status NICSR5<SS>, which indicates the failure reason. 


Information 


The self-test takes 25 ms to complete after hardware or software reset. 


If the initialization completes successfully, the SGEC is ready to accept further 
host commands. Both the reception and transmission processes are placed in the 
STOPPED state. 


Successive reset commands (either hardware or software) may be issued. The 
only restriction is that SG@EC NICSRs should not be accessed during a 1 us period 
following the reset. Access during this period will result in a CP-bus timeout 
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error. Access to SGEC NICSRs during the self-test are permitted; however, only 
NICSR5 reads should be performed. 


10.3.18.2 Interrupts 
Interrupts are generated as a result of various events. NICSR5 contains all the 
status bits that may cause an interrupt, provided NICSR6<IE> is set. The port 
driver must clear the interrupt bits (by writing a “1” to the bit position), to enable 
further interrupts from the same source. 


Interrupts are not queued, and if the interrupting event reoccurs before the 
port driver has responded to it, no additional interrupts will be generated. For 
example, NICSR5<RI> indicates one or more frames were delivered to host 
memory. The port driver should scan all descriptors from its last recorded 
position to the first SGEC owned one. 


An interrupt will be generated only once for simultaneous, multiple interrupting 
events. It is the port driver responsibility to sean NICSR5 for the interrupt 
cause(s). The interrupt will not be regenerated, unless a new interrupting event 
occurs after the host acknowledged the previous one, and provided the port 
driver cleared the appropriate NICSR5 bit(s). For example, NICSR5<TI> and 
NICSR5<RI> may both set, the host acknowledges the interrupt, and the port 
driver begins executing by reading NICSR5. Now NICSR5<RU> sets. The port 
driver writes back its copy of NICSR5, clearing NICSR5<TI> and NICSR5<RI>. 
After the host IPL is lowered below the SGEC level, another interrupt will be 
delivered with the NICSR5<RU> bit set. 


Should the port driver clear all NICSR5 set interrupt bits before the interrupt 
has been acknowledged, the interrupt will be suppressed. 


10.3.18.3 Startup Procedure 
A sequence of checks and commands must be performed by the port driver to 
prepare the SGEC for operation. 


1. Wait for the SGEC to complete its initialization sequence by polling on 
NICSR5<ID> and NICSR5<SF>. (Refer to Section 10.3.6 for details.) 


2. Examine NICSR5<SF> to find out whether the SGEC passed its self-test. If 
it did not, it should be replaced. (Refer to Section 10.3.6 for details.) 


3. Write NICSRO to establish system configuration dependent parameters. 
(Refer to Section 10.3.3 for details.) 


4. Ifthe port driver intends to use VAX virtual addresses, NICSR7 must be 
written to identify the system page table to the SGEC. (Refer to Section 10.3.8 
for details.) 


5. Ifthe port driver wishes to change the default settings of the watchdog 
timers, it must write to NICSR9. (Refer to Section 10.3.10 for details.) 


6. The port driver must create the transmit and receive descriptor lists, then 
write to NICSR3 and NICSR4 to provide the SGEC with the starting address 
of each list. The first descriptor on the transmit list will usually contain a 
setup frame. (Refer to Section 10.3.5 for details.) 


7. Write NICSR6 to set global operating parameters and start the transmission 
and reception processes. The reception and transmission processes enter 
the RUNNING state and attempt to acquire descriptors from the respective 
descriptor lists, and begin processing incoming and outgoing frames. (Refer 
to Section 10.3.7 for details.) The reception and transmission processes are 
independent of each other and can be started and stopped separately. 
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Caution 


If address filtering (either perfect or imperfect) is desired, the reception 
process should be started only after the setup frame has been processed. 


8. The port driver now waits for any SGEC interrupts. If either the reception 
or transmission processes were SUSPENDED, the port driver must issue the 
Poll Demand command after it has rectified the suspension cause. 


10.3.18.4 Reception Process 
While in the RUNNING state, the reception process polls the receive descriptor 
list, attempting to acquire free descriptors. Incoming frames are processed and 
placed in acquired descriptors’ data buffers, while status information is written 
to the descriptor RDESO words. The SGEC always tries to acquire an extra 
descriptor in anticipation of incoming frames. Descriptor acquisition is attempted 
under the following conditions: 


¢ Immediately after being placed in the RUNNING state through setting of 
NICSR6<SR>. 


¢ The SGEC begins writing frame data to a data buffer pointed to by the 
current descriptor. 


¢ The last acquired descriptor chained (RDES1<CA> = 1 ) to another descriptor. 


e A virtual translation error was encountered (RDESO<TN>) while the SGEC 
was translating the buffer base address of the acquired descriptor. 


As incoming frames arrive, the SGEC strips the preamble bits and stores the 
frame data in the receive FIFO. Concurrently, it performs address filtering 
according to NICSR6 fields AF, HP, and its internal filtering table. If the frame 
fails the address filtering, it is ignored and purged from the FIFO. Frames that 
are shorter than 64 bytes, due to collision or premature termination, are also 
ignored and purged from the FIFO unless NICSR6<PB> is set. 


After 64 bytes have been received, the SGEC begins transferring the frame 

data to the buffer pointed to by the current descriptor. If data chaining is 
enabled (NICSR6<DC> clear), the SGEC will write frame data overflowing the 
current data buffer into successive buffer(s). The SGEC sets the RDESO<FS> and 
RDESO<LS> in the first and last descriptors, respectively, to delimit the frame. 
Descriptors are released (RDES0<OW> bit cleared) as their data buffers fill up or 
the last segment of a frame has been transferred to a buffer. 


The SGEC sets RDESO<LS> and the RDESO status bits in the last descriptor it 
releases for a frame. After the last descriptor of a frame is released, the SGEC 
sets NICSR5<RI>. 


This process is repeated until the SGEC encounters a descriptor flagged as owned 
by the host. After filling up all previously acquired buffers, the reception sets 
NICSR5<RU> and enters the SUSPENDED state. The position in the receive list 
is retained. 


Any incoming frames while in this state will cause the SGEC to fetch the current 
descriptor in the host memory. If the descriptor is now owned by the SGEC, the 
reception reenters the RUNNING state and starts the frame reception. 


If the descriptor is still owned by the host, the SGEC increments the missed 
frames counter (NICSR10<MFC>) and discards the frame. 
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Table 10-40 summarizes the reception process state transitions and resulting 


actions: 


Table 10-40 Reception Process State Transitions 


From State Event To State Action 

STOPPED Start Reception command. RUNNING Receive polling begins from last 
list position or from the the 
list head if this is the first Start 
command issued, or if the receive 
descriptor list address (NICSR3) 
was modified by the port driver. 

RUNNING SGEC attempts acquisition of a SUSPENDED NICSR5<RU> is set when the 

descriptor owned by the host. last acquired descriptor buffer 
is consumed. Position in list 
retained. 

RUNNING Stop Reception command. STOPPED Reception process is STOPPED 
after the current frame, if any, 
is completely transferred to 
data buffer(s). Position in list 
retained. 

RUNNING Memory or host bus parity error STOPPED Reception is cut off and 

encountered. NICSR5<ME> is set. 

RUNNING Reset command. STOPPED Reception is cut off. 

SUSPENDED Rx Poll Demand or incoming RUNNING Receive polling resumes from 

frame and available descriptor. last list position or from the list 
head if NICSR3 were modified 
by the port driver. 

SUSPENDED Stop Reception command. STOPPED None. 

SUSPENDED Reset command. STOPPED None. 


10.3.18.5 Transmission Process 
While in the RUNNING state, the transmission process polls the transmit 
descriptor list for any frames to transmit. Frames are built and transmitted 
on the Ethernet wire. Upon completing frame transmission (or giving up), 
status information is written to the TDESO words. Once polling starts, it 


continues (in sequential or descriptor chained order) until the SGEC encounters a 
descriptor flagged as owned by the host, or an error condition. At this point, the 
transmission process is placed in the SUSPENDED state and NICSR5<TI> is set. 


NICSR5<TI> will also be set after completing transmission of a frame that has 
TDES1<IC> set in its last descriptor. In this case, the transmission process 
remains in the RUNNING state. 


Frames may be data chained and span several buffers. Frames must be delimited 
by TDES1<FS> and TDES1<LS> in the first and last descriptors, respectively, 
containing the frame. While in the RUNNING state, as the transmission process 
starts, it first expects a descriptor with TDES1<FS> set. Frame data transfer 
from the host buffer to the internal FIFO is initiated. Concurrently, if the current 
frame has TDES1<LS> clear, the transmission process attempts to acquire the 
next descriptor. It expects TDES1<FS> and TDES1<LS> to be clear, indicating 
an intermediary buffer, or TDES1<LS> to be set, indicating the end of the frame. 
After the last buffer of the frame has been transmitted, the SGEC writes back 
final status information to the TDESO word of the descriptor having TDES1<LS> 
set, optionally sets NICSR5<TI> if TDES1<IC> were set, and repeats the process 
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Table 10-41 Transmission Process State Transitions 


with the next descriptor(s). Actual frame transmission begins after at least 72 
bytes have been transferred to the internal FIFO, or a full frame is contained 
in the FIFO. Descriptors are released (TDESO<OW> bit cleared) as soon as the 


SGEC finishes processing them. 


Transmit polling suspends under the following conditions: 


¢ The SGEC reaches a descriptor with TDESO<OW> clear. To resume, the port 
driver must give descriptor ownership to the SGEC and issue a Poll Demand 


command. 


¢ The TDES1<FS> and TDES1<LS> are incorrectly paired or out of order. 


TDESO<LE> will be set. 


¢ A frame transmission is given up due to a locally induced error. The 


appropriate TDESO bit is set. 


The transmission process enters the SUSPENDED state and sets NICSR5<TI>. 
Status information is written to the TDESO word of the descriptor causing the 

suspension. The position in the transmit list, in all the above cases, is retained. 
The retained position is that of the descriptor following the last descriptor closed 


(set to host ownership) by the SGEC. 


Note 


The SGEC does not automatically poll the Tx descriptor list, and the port 
driver must explicitly issue a Tx Poll Demand command after rectifying 


the suspension cause. 


The following table summarizes the transmission process state transitions: 


From State Event To State Action 
STOPPED Start Transmission command. RUNNING Transmit polling begins 
from the last list position 
or from the head of the 
list if this is the first Start 
command issued, or if 
the transmit descriptor 
list address (NICSR4) 
was modified by the port 
driver. 
RUNNING SGEC attempts acquisition of a SUSPENDED NICSR5<TI> is set. 
descriptor owned by the host. Position in list retained. 
RUNNING Out of order delimiting flag SUSPENDED TDESO<LE> and 
(TDESO<FS> or TDESO<LS>) NICSR5<TI> are set. 
encountered. Position in list retained. 
RUNNING Frame transmission aborts due to a SUSPENDED Appropriate TDESO and 


locally induced error. 


10-50 Network Interface 


NICSR5<TI> bits are set. 
Position in list retained. 


(continued on next page) 


Network Interface 
10.3 Programming the SGEC 


Table 10—41 (Cont.) Transmission Process State Transitions 


From State Event To State Action 

RUNNING Stop Transmission command. STOPPED Transmission process 
is STOPPED after the 
current frame, if any, is 
transmitted. Position in 
list retained. 

RUNNING Transmit watchdog expires. STOPPED Transmission is cut off 
and NICSR5<TW>, 
TDESO<TO> are set. 
Position in list retained. 

RUNNING Memory or host bus parity error STOPPED Transmission is cut off 

encountered. and NICSR5<ME> is set. 

RUNNING Reset command. STOPPED Transmission is cut off. 

SUSPENDED Tx Poll Demand command. RUNNING Transmit polling resumes 
from last list position 
or from the list head if 
NICSR4 were modified by 
the port driver. 

SUSPENDED Stop Transmission command. STOPPED None. 

SUSPENDED Reset command. STOPPED None. 


10.3.18.6 Loopback Operations 
The SGEC supports two loopback modes: 


Internal loopback 

This mode generally is used to verify correct operations of the SGEC internal 
logic. While in this mode, the SGEC will take frames from the transmit list 
and loop them back, internally, to the receive list. The SGEC is disengaged 
from the Ethernet wire while in this mode. 


External loopback 


This mode generally is used to verify correct operations up to the Ethernet 
cable. While in this mode, the SGEC will take frames from the transmit list 
and transmit them on the Ethernet wire. Concurrently, the SGEC listens to 
the line that carries its own transmissions and places incoming frames in the 
receive list. 


Note 


Caution should be exercised in this mode as transmitted frames are 
placed on the Ethernet wire. Furthermore, the SGEC does not check 
the origin of any incoming frames; consequently, frames not necessarily 
originating from the SGEC might make it to the receive buffers. 


In either of these modes, all the address filtering and validity checking rules 
apply. The port driver needs to take the following actions: 


1. Place the reception and transmission processes in the STOPPED state. The 


port driver must wait for any previously scheduled frame activity to cease. 
This is done by polling the TS and RS fields in NICSR5. 
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2. Prepare appropriate transmit and receive descriptor lists in host memory. 
These may follow the existing lists at the point of suspension, or may be new 
lists that will have to be identified to the SGEC by appropriately writing 


NICSR3 and NICSR4. 


3. Write to NICSR6<OM> according to the desired loopback mode, and place the 
transmission and reception processes in the RUNNING state through Start 


commands. 


4. Respond and process any SGEC interrupts, as in normal processing. 


To restore normal operations, the port driver must execute step 1, then write the 


OM field in NICSR6 with “00.” 


10.3.18.7_ DNA CSMA/CD Counters and Events Support 


This section describes the SGEC features that support the port driver in 
implementing and reporting the specified counters and events !. 


Table 10-42 CSMA/CD Counters 


Counter 


SGEC Feature 


Time since counter creation 


Bytes received 
Bytes sent 
Frames received 
Frames sent 


Multicast bytes received 


Multicast frames received 
Frames sent, initially deferred 
Frames sent, single collision 
Frames sent, multiple collisions 
Send failure- Excessive collisions 
Send failure- Carrier check failed 


Send failure- Short circuit 


Supported by the host driver. 


Port driver must add up the RDESO<FL> fields of all 
successfully received frames. 


Port driver must add up the TDES2<BS> fields of all 
successfully transmitted buffers. 


Port driver must count the successfully received frames 
in the receive descriptor list. 


Port driver must count the successfully transmitted 
frames in the transmit descriptor list. 


Port driver must add up the RDESO<FL> fields of all 
successfully received frames with multicast address 
destinations. 


Port driver must count the successfully received frames 
with multicast address destinations. 


Port driver must count the successfully transmitted 
frames with TDESO<DE> set. 


Port driver must count the successfully transmitted 
frames with TDESO<CC> equal to 1. 


Port driver must count the successfully transmitted 
frames with TDESO<CC> greater than 1. 


Port driver must count the transmit descriptors having 
TDESO<EC> set. 


Port driver must count the transmit descriptors having 
TDESO<LC> set. 


Two successive transmit descriptors with the No_ 
carrier flag TDESO<NC> set, indicates a short circuit. 


(continued on next page) 


Specified in the DNA Maintenance Operations (MOP) Functional Specification, Version 


T.4.0.0, 28 January 1988. 
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Counter 


SGEC Feature 


Send failure- Open circuit 


Send failure- Remote Failure to Defer 
Receive failure- Block Check Error 
Receive failure- Framing Error 
Receive failure- Frame too long 


Unrecognized frame destination 


Data overrun 
System buffer unavailable 


User buffer unavailable 
Collision detect check failed 


Two successive transmit descriptors with the 
Excessive_collisions flag TDESO<EC> set with the 
same Time domain reflectometer value TDESO<TDR>, 
indicate an open circuit. 


Flagged as a late collision TDESO<LC> in the transmit 
descriptors. 


Port driver must count the receive descriptors having 
RDESO<CE> set with RDESO<DB> cleared. 


Port driver must count the receive descriptors having 
both RDESO<CE> and RDESO<DB> set. 


Port driver must count the receive descriptors having 
RDESO<TL> set. 


Not applicable. 


Port driver must count the receive descriptors having 
RDESO<OF> set. 


Reported in the Missed_frame counter 
NICSR10<MFC>. (Refer to Table 10-20.) 


Not applicable. 


Port driver must count the transmit descriptors having 
TDESO<HF> set. 


CSMA/CD specified events can be reported by the port driver based on the above 
table. The Initialization Failed event is reported through NICSR5<SF>. 
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KA680 Mass Storage Interface 


The KA680 contains a DSSI bus interface, which is implemented with the single 
host adapter chip (SHAC). This interface allows the KA680 to transmit packets 
of data to, and receive packets of data from, up to seven other DSSI devices 
(typically RF-type disk drives and TF-type streaming tape drives). It should also 
be noted that the SHAC supports CP-bus parity protection. 


11.1 SHAC Introduction 


SHAC (single host adapter chip) is a single-chip, VLSI version of an SCA port 
that uses a DSSI bus as the physical interconnect. Another SCA realization, CI, 
has defined a port driver/port interface, which has been used to connect VAX 
systems in clusters. DSSI has adopted the same interface so that the same VMS 
port driver will be able to drive either a CI port or SHAC. The SHAC can be used 
to connect a host to any other device that can communicate through the CI-DSSI 
protocol. In particular, it provides a solution to the following: 


¢ The problem of interfacing a group of mass-storage device controllers 
(MSDCs) to a VAX system. 


¢ The problem of interfacing several VAX systems to a common group of MSDCs 
and, if higher level protocols support this option, to one another. 


Where two or more VAX systems connect to a group of MSDCs (or to one another) 
through DSSI, each has a SHAC or another DSSI port. When a group of MSDCs 
connect to the DSSI bus, the controllers provide both the bus interface and the 
intelligent control required to respond to the CI commands received over the 
DSSI. 


On the 1-byte wide DSSI bus, both the MSDCs and the VAX systems 
communicate at high speed, with a 4 to 5 MB/s burst transfer rate. The SHAC 
handles the problem of providing effective, efficient, and reliable interfacing 
between this DSSI bus and the CPU , having direct host memory access (DMA) 
over the host’s 32-bit wide, 16 MB/s CP-bus. All communications between those 
connected to the DSSI will follow the CI protocol, with the DSSI protocols 
providing handshaking in the transactions. 


Structural parameters limit the number of possible combinations that can be 
realized with DSSI and SHAC. 


¢ A single DSSI bus has room for eight nodes, which may be partitioned among 
host adapters (for example, SHACs) and MSDCs. 


¢ Up to four SHACs can be installed on a single host bus. 


¢ Because there must be a host, there can be up to seven MSDCs on a single 
DSSI. 
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The SHAC provides a small amount of buffering (1.2 KB) on chip to improve bus 
utilization on both sides, but the SHAC is designed to pass data from one bus to 
the other as rapidly as the two buses permit. DMA services to and from the main 
memory reside in the SHAC, which responds to requests for transfers between 
the host and the remote nodes. 


The SHAC is operated by an on-chip RISC that obtains its code and internal 
data from on-chip RAM and ROM. The RAM will be loaded from main memory 
during both initialization and as circumstances require during normal run time. 
With this capability, it can read in new code and data from the main memory and 
adapt its behavior to new circumstances. This will permit inexpensive upgrades 
of SHACs after they are installed in the field. Furthermore, it will allow the 
SHAC to store infrequently accessed code in main memory, providing more 
capability than could be included in on-chip ROM. 


The overall communication architecture under which the SHAC works is Digital’s 
systems communications architecture (SCA). In this general architecture, four 
layers are defined, as shown in Figure 11-1. The architecture can be realized in 
a variety of ways. Two of the lowest two levels in the diagram are CI (computer 
interconnect) and DSSI (Digital storage system interconnect). They share the 
same lowest host layer (CI port driver) but have distinctly different physical 
interconnects. The layers between the port driver and the DSSI bus itself can 
be realized at both board and chip level, and products at both levels are being 
designed in Digital. The SHAC is a chip-level product connecting the host bus to 
the DSSI bus, and is controlled by the CPU through a CI port driver. It accepts 
and delivers ClI-defined packets over the DSSI bus. Layers above the port driver 
are invisible to SHAC. 


Figure 11-1 Relationship of the DSSI to SCA and Cl 
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The port driver maintains a set of seven queues in its system space. Four of 
these contain commands for the SHAC to execute. The priority of the command 
is determined by the queue it is on; order is determined by the position in the 
queue. Another queue contains all the responses for the host (from the SHAC or 
the remote nodes). There are two also queues of "empty envelopes” for the host 
and the SHAC to use to stuff with commands and responses, and then to queue 
them on the other queues. 
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These "envelopes" are simply standard-sized "queuable" blocks of host memory. 
All commands and responses are copied into one of these standard-sized blocks. 
Included in the header on each block are a pair of queue pointers (for a doubly 
linked queue) and various standard identifiers that specify what is contained in 
the block, and how much of the block represents the actual command or response. 
To be visible, a block must be on a queue where pointers from other elements or 
the queue header show its presence. Once a block is removed from a queue, it is 
visible only to the entity that removed it. 


The SHAC’s principal task is in accepting and delivering "mail" to other nodes. 
Externally (for example, on DSSI), the SHAC deals only in standard CI formats. 
Internally, the SHAC deals with the envelopes just described and with blocks 
of data. Because DSSI deals with bytes and the CP-bus deals in longwords, the 
SHAC must frequently do byte alignment tasks during transcription. 


The SHAC deals with the port driver in the virtual address mode, unloading from 
the CPU the obligation to do virtual-to-physical address translation and to be 
aware of page crossings in virtually contiguous blocks of information. The SHAC 
supports full virtual address translation including the use of global I/O pages (to 
a depth of 1). 


The rest of this SHAC overview section describes a typical set of steps that the 
SHAC covers in serving its role as the CI port with "mail" in both directions. 


11.2 CI-DSSI Overview 


At startup, the host provides the SHAC with a number of pointers to internal 
host structures. One of them, the port queue block (PQB), contains pointers and 
data on all the queues that the host maintains for CI. The SHAC uses this data 
to carry on its normal business in the following way. 


If traffic is not coming in on the DSSI bus, the SHAC goes to the highest 
command queue that has something enqueued. Choices are CMDQ0..CMDQ3, 
with 3 being most urgent. It dequeues an element from the queue and examines 
its header to see what it must do with the queue entry. It could be a command for 
the SHAC or an item to be delivered to one of the nodes on the DSSI. A command 
might be an order to deliver a block of data to a remote node. An item to be 
delivered would be either a datagram or a message. 


A datagram is a "one-sided" communication—that is, one that will be sent 
without any assurance of either receipt or reply. An obvious application for such 
a communication is a request for the party at the other node to identify itself. 

If the host does not know if anything is out there, it must transmit its request 
without expectation. For this or any similar purpose, it employs a datagram. All 
datagrams are of lengths guaranteed to fit in a datagram envelope. 


A message is a "two-sided" communication used when a virtual circuit (an 
established formal relationship) between members of the bus exist. Once such 

a virtual circuit is established, the host(s) understand how to make requests of 
the other side. Such a request could be an order for a data transfer in either 
direction. The message itself (move data) is contained in a command (deliver 
this message to ...). All messages are of lengths guaranteed to fit in a message 
envelope. Messages are always delivered sequentially to a given node—that is, in 
the order in which they were enqueued on a particular queue. While the SHAC 
supports retries if a message fails to get through, once the retry limit is reached 
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without successful delivery, SHAC returns the command to the host, marking it 
as undeliverable, and then breaks the virtual circuit to that node. 


A full transaction might go something like this: 


1. 


The host queues a message for node 3 (for example, a disk controller) to 
copy a block of 16 KB from host memory, starting at location X and to be 
stored in location Y on disk. The queues are doubly linked, so at the top of 
every envelope there is a forward link FLINK and a backward link BLINK. 
Enqueuing involves putting link values into the new element’s FLINK and 
BLINK, and making the previous last element’s FLINK and the queue 
header’s BLINK point to the new element. 


When this message gets to the head of the queue, the SHAC dequeues it 1, 
reads the header, and finds that it should "dial up" node 3. To do this, the 
SHAC goes through the DSSI protocols, contending for the DSSI bus and 
then, if successful in getting bus, specifying node 3 as the target. These steps 
are called arbitration and selection. 


Node 3 responds by asking for the DSSI command (command-out phase). In 
this phase, the SHAC tells node 3 how many bytes are coming and repeats 
the identification information to confirm a proper selection. Node 3 then tells 
the SHAC to switch to the data-out phase. The SHAC sends a pair of CI 
header bytes to identify what type of message this is, and then proceeds to 
transmit the actual message read from the message block in host memory. 
The step-by-step details of the transfer are handled by hardware in the 
SHAC, which permits simultaneous, buffered reading and writing on the 
two buses to which the SHAC is connected. Upon proper completion of the 
transmission, node 3 responds with a 1-byte acknowledgment of success 
(parity and check-sum proper and no other errors). 


The SHAC is still holding the only pointer to the message block in host 
memory. It returns this to the host in one of two ways. If the host has 
requested a "return receipt," the SHAC puts the block on the response queue 
RSP@Q to indicate proper delivery. This is where the port driver software in 
the host will look for responses. 


Alternatively, the SHAC simply puts it back on the MFREEQ, which holds 
the standard envelopes for messages. At this point, the single message has 
been delivered and the message envelope is back in circulation. 


After whatever delay node 3 needed to process the message, it contends for 
the bus and upon winning it, selects the SHAC as its target. It then sends 

a standard CI message as above telling the SHAC to transmit the required 
data. In general, the SHAC does not do this immediately, because it is obliged 
to handle traffic according to position in the queue and according to queue 
priority. Instead, it takes an empty envelope from MFREEQ, writes into it 
the message it is receiving, and puts it on the proper CMDQ as specified in 
the message it just received. 


When that message gets to the head of its queue, the SHAC dequeues it 
once more, carries out its command (in transmissions of 4 KB whenever 
possible—a 4 KB transmission takes about 1 ms on the DSSD, possibly 
interleaving other transmissions of higher priority to this node or any priority 
to other nodes, until the last byte is sent. Once the SHAC has completed this 
operation, it returns the message block to the MFREEQ. 


1 


Note that the SHAC ends up holding the only pointer to the dequeued block of memory 
that constitutes the queue element. The port driver no longer "knows" where it is. 
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7. Node 3 has put its data on the disk and must report to the host the successful 
completion of the transaction. Again, it contends for the bus and upon 
winning, specifies the SHAC as its target. Then it sends a message to the 
port driver through the SHAC, confirming the successful transaction. The 
SHAC dequeues another free envelope and writes this message into that 
block. Then it queues it on the host’s RSPQ. Except for higher level responses 
in the host, that concludes a whole transaction. 


The enqueue/dequeue operations represent a considerable portion of the effort in 
delivering a message or datagram. To minimize this effort, the SHAC caches a 
small number of the envelopes (that is, it hangs onto the pointers to the memory 
blocks) as they become free in its normal activity. It only fetches an envelope 
from the free queues when its own supply has disappeared, and it only returns 
them to the free queues when it has a full supply (four of a type). By this and 
other attention to effort reduction and traffic conservation, the SHAC attempts to 
optimize its rate of doing useful work. 


11.3 SHAC Registers 


The CPU communicates directly with the SHAC chip through a set of device 
registers in each SHAC. These registers occupy a 1-page (512-byte) region in I/O 
address space, aligned on a page boundary. 


All the registers are longword registers. They may be accessed only through 
longword operations. 


In addition to the access restrictions listed for specific registers, no register other 
than SHAC software chip reset (SSWCR) may be read or written while certain 
chip intialization functions are being executed. The results of such an access 
during the 100 milliseconds following a reset (powerup or a write to SSWCR), 

or during the 50 microseconds following a MIN-bit (PMCSR<0>) reset, are 
unpredictable. 


The registers can be divided into two categories: 


¢ The CI port registers defined in the CI Port Architecture 
specification 


¢ The SHAC specific registers 
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11.3.1 Cl Port Registers 


11.3.1.1| Port Queue Block Base Register (PQBBR) 
SHAC I/O Address: 2000 4048; ¢ 


This port queue block base register (PQBBR) contains the uppermost bits of the 
physical address of the base of the port queue block (PQB). After a reset, the 

PQBBR is loaded by the SHAC with configuration information. This information 
remains in the PQBBR until the PQBBR is written with the address of the port 
queue block. Figure 11—2 shows the format. Table 11—1 lists the bit descriptions. 


PQBBR is writable only when the port is in the disabled or disabled/maintenance 
state and readable anytime (except during chip initialization). 


Figure 11-2 Port Queue Block Base Register (PQBBR) 
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Table 11-1 Port Queue Block Base Address Register (PQBBR) 


Data Bit Name Description 

<31:21> MBZ Read as zero, must be written as zero. 

<20:0> PQB Base This field contains the uppermost bits of the physical 
<29:9> address of the base of the port queue block (PQB). Note 


that the PQB must be page-aligned, so the remaining 
bits of the address are assumed to be zero. 
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Following chip reset, PQBBR contains the configuration shown in Figure 11-3. 
The bit descriptions are listed in Table 11-2. 


Figure 11-3 Port Queue Block Base Register (PQBBR) After Reset 
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Table 11-2 Port Queue Block Base Address Register Bits After Reset 


Data Bit Name Description 

<31:24> HW Ver. Hardware version. The hardware version of the SHAC 
that is greater than zero. 

<23:16> FW Ver. Firmware version. The firmware version of the SHAC 
that is greater than zero. 

<15:8> SHW Ver. Shared host memory version. The shared host memory 


version of the SHAC, which is zero until the shared 
host memory data area has been read. Thereafter, it is 
greater than zero. 


<7:0> Maint ID CI port maintenance ID. The CI port maintenance ID 
should always be 2216. 
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11.3.1.2 Port Status Register (PSR) 
SHAC I/O Address: 2000 404C1¢ 


The port status register (PSR) contains a status report. If interrupts are enabled, 
for example (PMCSR<2>) set, the port interrupts the CPU each time that it 
writes to this register. Once an interrupt is requested by the port, the value of 
PSR is fixed and is not changed until the CPU releases it by writing the port 
status release control register (PSRCR). The port status register format is shown 
in Figure 11-4 and the bit descriptions are in Table 11-3. 


PSR is read-only and may be read anytime by the port driver, except during chip 
initialization. Its value following a write to it is unpredictable. 


Figure 11-4 Port Status Register (PSR) 
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Table 11-3 Port Status Register Bit Descriptions 


Data Bit Name Description 


<31> MTE Maintenance error. When set, the port has detected an 
implementation specific error (or hardware status condition). 
The source of the error may be more accurately determined from 
the other bits in the upper word of this register (PSR) and the 
contents of other registers. Also, when set, the port is in the 
uninitialized state (port is nonfunctional). Maintenance errors 
normally indicate a severe SHAC hardware or software failure. 


<30:22> MBZ Read as zero, writes have no effect. 


(continued on next page) 
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Table 11-3 (Cont.) Port Status Register Bit Descriptions 


Data Bit Name Description 


<21> II Illegal interrupt. When set, this bit indicates a SHAC internal 
error, detected when the SHAC’s microprocessor received an 
interrupt from an invalid source. This causes ME (PSR<31>) 
to set and the port to enter the uninitialized state (port is 
nonfunctional). 


<20> QDE QUIP detected error. When set, this bit indicates a SHAC 
internal error detected when the SHAC’s microprocessor (QUIP) 
was given an invalid instruction. This causes ME (PSR<31>) 
to set and the port to enter the uninitialized state (port is 
nonfunctional). 


<19> DE Diagnostic error. When set, an error was detected while the 
SHAC was running its internal self-test. This causes ME 
(PSR<31>) to set and the port to enter the uninitialized state 
(port is nonfunctional). 


<18> ISN Illegal segment number. When set, this indicates a SHAC 
internal error in which it attempted to load a nonexistent 
external segment from the SHAC shared host memory. 
This causes ME (PSR<31>) to set and the port to enter the 
uninitialized state (port is nonfunctional). 


<17> SMPE Slave mode parity error. This bit is set by the occurrence of a 
parity error during a CPU access of a SHAC device register. 
This causes ME (PSR<31>) to set and the port to enter the 
uninitialized state (port is nonfunctional). 


<16> SHME Share host memory error. This bit is set by the occurrence of an 
error involving the SHAC shared host memory. This causes ME 
(PSR<31>) to set and the port to enter the uninitialized state 
(port is nonfunctional). 


<15:8> MBZ Read as zero, writes have no effect. 


<7> MISC Miscellaneous. When set, this bit indicates that the port 
microcode has detected one of the miscellaneous errors and 
the port is about to enter the disabled /maintenance state. The 
actual error code is stored in the port error status register. 


<6> ME Maintenance timer expiration. When set, the maintenance timer 
has expired. The port is in the uninitialized/maintenance state. 


<5> MSE Memory system error. When set, the port has encountered an 
uncorrectable data or nonexistent memory error in referencing 
memory. Port is in the disabled or disabled /maintenance 
state. See the port failing address register (PFAR) for further 
information. 


<4> DSE Data structure error. When set, the port has encountered 
an error in a port data structure (for example, queue entry, 
PQB, BDT, or page table). Port is in the disabled or disabled 
/maintenance state. See the port error status register (PESR) 
and the port failing address register (PFAR) for further 
information. Note that errors in queue structures leave the 
queues locked. 


<3> PIC Port initialization complete. When set, the port has completed 
internal initialization. The port is in the disabled or disabled 
/maintenance state. 


(continued on next page) 
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Table 11-3 (Cont.) Port Status Register Bit Descriptions 


Data Bit Name Description 


<2> PDC Port disable complete. When set, the port is in the disabled or 
disabled /maintenance state. 


<I> MFQE Message free queue empty. When set, the port attempted to 
remove an entry from the message free queue (MFREEQ) and 
found it empty. Port processing of commands continues, and the 
MFREEQ may not be empty at the time the port driver gets 
control. 


<0> RQA Response queue available. When set, this bit indicates port has 
inserted an entry on an empty response queue. 
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11.3.1.3 Port Error Status Register (PESR) 
SHAC I/O Address: 2000 405016 


The port error status register (PESR) indicates the type of error that resulted 
in a DSE (PSR<4>) or an MISC (PSR<7>) error. Figure 11-5 shows the format. 
Table 11—4 lists the bit descriptions. 


PESR is read-only by the CPU and valid only after either a DSE or MISC error, 
or after certain ME (PSR<31>) and DE (PSR<19>) errors. Its value at any other 
time, or following a write to it, is unpredictable. 


Figure 11-5 Port Error Status Register (PESR) 
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Longword Read Only Access 
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Table 11-4 Port Error Status Register Bit Definitions 


Data Bit Name Description 


<31:16> MEC Miscellaneous error code. This code comprises two 
fields: bits <31:24> define the the module within the 
SHAC code where the error occurred, and bits <23:16> 
contain the specific error that occurred. These codes are 
implementation-specific. 


<15:0> DEC Data structure error code. 
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11.3.1.4 Port Failing Address Register (PFAR) 
SHAC I/O Address: 2000 405416 


The format for the port failing address register is shown in Figure 11-6. 


After a DSE, MSE, and ME or DE error (as indicated by PSR), or after a response 
with buffer memory system error status, the port failing address register (PFAR) 
contains the memory address at which the failure occurred. The address may 

be the exact failing address, an address in the same page as the exact failing 
address or, in the case of DSE, an address in some part of the data structure. For 
DSE, PFAR contains a virtual address or offset, while for MSE interrupts and 
buffer memory system errors, PFAR contains a physical address. For ME, the 
interpretation of the address is error-dependent. 


Because the port continues command execution and packet processing after buffer 
memory system errors, the PFAR is overwritten if subsequent errors occur. For 
DSE, MSE, and ME errors the PFAR is effectively fixed because the port enters 
the disabled, disabled /maintenance, or uninitialized state. 


PFAR is read-only by the CPU and is readable after a DSE, MSE, or ME or DE 
errors or after a response with buffer memory system error status. Its value at 
any other time, or following a write to it, is unpredictable. 


Figure 11-6 Port Failing Address Register (PFAR) 0 


Failing Address 


Longword Read Only Access 


ESB90P0073 
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11.3.1.5 Port Parameter Register (PPR) 
SHAC I/O Address: 2000 4058;¢ 
The port parameter register (PPR) contains port implementation parameters and 
the port number. The value of the PPR is set by the port during initialization 
and is valid after a PIC (PSR <3>) interrupt. Its value at any other time, or 
following a write to it, is unpredictable. PPR is read only by the CPU . The port 


parameter register format is shown in Figure 11—7. The bit descriptions are listed 
in Table 11-5. 


Figure 11-7 Port Parameter Register (PPR) 
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Longword Read Only Access 
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Table 11-5 Port Parameter Register Bit Descriptions (PPR) 


Data Bit Name Description 


<31:29> CSZ Cluster size. For SHAC, this value always is zero, 
indicating a maximum of 16 ports on the DSSI bus. 
(Note that the DSSI architecture only allows up to 8 
ports on the bus, but 16 is the smallest size defined for 
the CSZ field.) 


<28:16> IBUF_LEN Internal buffer length. This field indicates the size 
of internal buffers available for message and data 
transfers. Maximum data packet = IBUF_LEN - 16 
bytes. Maximum message or datagram length = IBUF_ 
LEN. For SHAC, the value is 4112 101046. 


<15> MBZ Read as zero, writes have an unpredictable effect. 


<14:8> ISDI Implementation-specific diagnostic information. 
The bits in this field contain information about the 
local adapter’s link layer configuration. For SHAC, the 
definitions of these bits are read as zero. 


<7:0> Port_NO Port number. This is the same as the SHAC’s DSSI ID. 


11.3.1.6 Port Control Registers 
The port control registers are 32-bit registers that are write-only by the CPU . To 
invoke the function provided by any of the control registers, the CPU writes a one 
to the register. 


The result of writing any other value to any of these registers is unpredictable. 
The value read from any of them is also unpredictable. The format for the port 
control registers is shown in Figure 11-8. 
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Figure 11-8 Port Control Registers 
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11.3.1.6.1 Port Command Queue 0 Control Register (PCQOCR) SHAC I/O 
Address: 2000 408016 


When the port driver inserts an entry in an empty CMDQ0, the port driver 
writes PCQOCR to initiate port execution of the command queue. PCQOCR can 
be written only when the port is in the enabled or enabled /maintenance state. 
Writing to PCQOCR when the port is in any other state has no effect. 


11.3.1.6.2 Port Command Queue 1 Control Register (PCQ1iCR) SHAC I/O 
Address: 2000 4084, Same as PCQOCR, except refers to CMDQ1. 


11.3.1.6.3 Port Command Queue 2 Control Register (PCQ2CR) SHAC I/O 
Address: 2000 4088,g Same as PCQOCR, except refers to CMDQ2. 


11.3.1.6.4 Port Command Queue 3 Control Register (PCQ3CR) SHAC I/O 
Address: 2000 408C,g Same as PCQOCR, except refers to CMDQ3. 


11.3.1.6.5 Port Datagram Free Queue Conirol Register (PDFQCR) SHAC I/O 
Address: 2000 4090;g When the port driver inserts an entry on the DFREEQ 
and the latter was previously empty, the port driver writes PDFQCR to indicate 
the availability of DFREEQ entries. PDFQCR can be written only if the port is in 
the enabled or enabled/maintenance state. Writing to PDFQCR when the port is 
in any other state has no effect. 


11.3.1.6.6 Port Message Free Queue Control Register (PMFQCR) SHAC I/O 
Address: 2000 4094, Same as PDFQCR, except refers to MFREEQ. 


11.3.1.6.7 Port Status Release Control Register (PSRCR) SHAC I/O Address: 
2000 4098,, After the port driver has received an interrupt and read the PSR, it 
returns the PSR to the port by writing PSRCR. 


11.3.1.6.8 Port Enable Control Register (PECR) SHAC I/O Address: 2000 
409C,g The port driver enables the port by writing PECR. PECR is ignored if 
the port is in the uninitialized, uninitialized /maintenance, enabled, or enabled 
/maintenance state. 
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11.3.1.6.9 Port Disable Control Register (PDCR) SHAC I/O Address: 2000 
40A0,,¢ The port driver disables the port by writing PDCR. When the port is 
disabled, the port sets PDC (PSR <2>), and if interrupts are enabled, requests 
an interrupt. PDCR is ignored if the port is in the wninitialized, uninitialized 
/maintenance, disabled, or disabled /maintenance state. 


11.3.1.6.10 Port Initialize Control Register (PICR) SHAC I/O Address: 

2000 40A4,¢ The port driver initializes the port by writing PICR. When the 
initialization is complete, the port sets PDC (PSR <2>) and requests an interrupt 
if interrupts are enabled. As part of the initialization, the maintenance timer is 
set to expire in 100 seconds. 


11.3.1.6.11_ Port Maintenance Timer Control Register (PMTCR) SHAC I/O 
Address: 2000 40A8,¢ The port driver forces the maintenance timer to reset 
its expiration time by writing the PMTCR. If the PMTCR is not written again 
before the expiration time, the port will enter the uninitialized /maintenance 
state setting MTE (PSR <6>), and request an interrupt if interrupts are enabled. 
PMTCR is ignored if the maintenance timer is not running. 


11.3.1.6.12 Port Maintenance Timer Expiration Control Register (PMTECR) 
SHAC I/O Address: 2000 40AC,¢ The port driver forces a maintenance-timer- 
expiration interrupt by writing the PMTECR. This register may be written only 
when the port is in the enabled, enabled / maintenance, disabled, and disabled 
/maintenance states, and only while the maintenance timer is not disabled. 


11.3.1.6.13 Port Maintenance Control and Status Register (PMCSR) SHAC 
I/O Address: 2000 405C,g The port maintenance control and status register 
(PMCSR) is used for maintenance level control and status reporting. The CI Port 
specification defines all but the two least significant bits. The format is shown in 
Figure 11-9 and the bit descriptions are listed in Table 11-6. 


The bits can be divided into the following categories: 


¢ Status bits - Set by the port to report various conditions. They are cleared 
by maintenance initialization or clearing the condition in another register. 
PMCSR does not include any status bits at this time. 


¢ Function control bits are read/write by the port driver only. They are clear on 
a reset. 


These bits are divided into two classes: 


1. Init: This type of bit invokes a function (for example, initialization) by 
setting it. It always reads as zero, except while the function is active. 


2. Enable/disable: This type of bit causes an activity or state to exist while 
the bit is set. Clearing the bit stops the activity or changes the state. 
The bit always reads the most recently written value. The bit is never 
changed by the port. 
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Figure 11-9 Port Maintenance Conirol And Status Register (PMCSR) 
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Table 11-6 Port Maintenance Control and Status Register (PMCSR) Bits 


Data Bit 


Name 


Description 


<31:5> 


<4> 


<3> 


<2> 


<l> 


<0> 


RESERVED 


HAC 


SIMP 


TE 


MTD 


MIN 


These bits are reserved. They should not be written; 
reads return unpredictable results. 


Host access feature. This bit must be zero, except for 
diagnostic purposes. This is an enable/disable class 
control bit. 


Simple SHAC mode. Must be zero, except for diagnostic 
purposes. This is an enable/disable class control bit. 


Interrupt enable. When set, interrupts from the port to 
the CPU are enabled. Power-up state is clear (interrupts 
disabled). This is an enable/disable class control bit. 


Maintenance timer disable. Read/write by CPU . If set, 
the maintenance timer is turned off. Timer is set to the 
initial value and suspended. If clear, timer functions 
normally. Power-up state is clear (timer enabled). This 
is an enable/disable class control bit. 


Maintenance init. Writing a one to this bit resets the 
port. Upon completion, the port is in the uninitialized 
state and MIN is clear. Writing a zero to this bit has no 
effect. It always reads as zero, except while the reset 
function is active. 


Although maintenance init resets the port, it is not 
equivalent to a write to the SHAC software chip reset 
register. In particular, the SHAC shared host memory 
address is not reset by maintenance init. 


11.3.2 SHAC Specific Registers 


These registers, which are not defined in the CI port architecture, are used for 
additional maintenance level control. 
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11.3.2.1| SHAC Software Chip Reset Register (SSWCR) 
SHAC I/O Address: 2000 403016 


When the CPU writes FFFF FFFF 1g, to the SHAC software chip reset register 
(SSWCR), a chip reset is performed. The result is equivalent to that of the 
hardware chip reset that occurs following system powerup. On completion, 
all device registers are reset to their power-up state, and the port is in the 
uninitialized state. The format is shown in Figure 11-10. 


SSWCR is write-only by the CPU and may be written to at any time. Its value 
when read is unpredictable. The result, if other than FFFF FFFF jg, is written to 
SSWCR as undefined. 


Figure 11-10 SHAC Software Chip Reset (SSWCR) 
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11.3.2.2 SHAC Shared Host Memory Address (SSHMA) 
SHAC I/O Address: 2000 40441, 


The format for the SHAC shared host memory address is shown in Figure 11-11. 


Figure 11-11 SHAC Shared Host Memory Address (SSHMA) 
3.3 2 
109 4 3 0 


MBZ SSHMA<29:4> MBZ 


Longword Read/Write Access 
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Following chip reset, the CPU writes the physical address of the shared host 
memory header into the SHAC shared memory address register (SSHMA). The 
area must be octaword-aligned and contiguous in physical memory. 


SSHMA is read/write by the CPU , but may be written only when the port is in 
the uninitialized state. Writing when the port is in any other state can produce 
unpredictable results. 


KA680 Mass Storage Interface 11-17 


12 


KA680 Firmware 


12.1 KA680 Firmware Overview 


This chapter describes the KA680 functional firmware. The firmware is VAX—11 
code, which resides in FEPROM on the KA680 module. Typically KA680 firmware 
gains control whenever the on-board CPU "halts," or more precisely, performs 

a "processor restart” operation. However, portions of the firmware can also be 
invoked by applications through a public subroutine linkage. 


When the KA680 firmware is running, it provides services expected of a standard 
VAX console subsystem. In particular, the following services are available: 


¢ Automatic restart or bootstrap of customer application images at powerup, on 
reset, or conditionally after processor halts 


¢ Diagnostic tests executed both at powerup and by request, which verify the 
correct operation of the CPU and memory modules 


¢ Operator interface providing complete examination or modification of the 
processor state 


A more detailed description of the major components of the KA680 is provided in 
Section 12.2, and a structural diagram of the KA680 firmware is shown in Figure 
12-1. 


Throughout this chapter, "firmware" is a generic term describing all program 
code located in the KA680 FEPROM. Sometimes it is referred to as either the 
"boot ROM," "diagnostics ROM," or "console ROM," depending on context. Each 
major element of the firmware is referred to by other terms (for instance, the boot 
program as "VMB'" or "primary bootstrap," the ROM-based diagnostic program 

as the "diagnostic" or "self-test," and the operator interface as the "console" or 
"console program"). 


Certain terminology and conventions are used throughout this chapter. With one 
exception, numbers (unless otherwise indicated or implied) are decimal. Eight- 
digit numbers throughout this document are hexadecimal longwords, typically 
representing VAX 32-bit addresses or data. Where there is ambiguity, the radix is 
explicitly stated. For instance, 72 is assumed to be decimal and for clarity can be 
written as 72 (dec). However, alternate representations for 72 are 1001000 (bin) 
for binary, 110 (oct) for octal, or 48 (hex) for hexadecimal. On the other hand, 
0040000 is the hexadecimal address or the base of the firmware FEPROM. 


Ranges of integers are expressed as a pair of numbers separated by a colon and 
are always inclusive. For example, 7:4 specifies the range of integers from 7 to 4 
(namely, 7, 6, 5, and 4). 
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A bit field or position within a register or data structure follows the structure 
name and is enclosed in angle brackets. The associated field name (if defined) 
typically follows the field definition and appears in parentheses. For instance, 
PSL<20:16> (IPL) represents the 5-bit field for the interrupt priority level in the 
processor status longword. 

12.2 Firmware Capabilities 


The KA680 firmware provides the following services: 


¢ Diagnostics that test all components on the board and verify the module is 
working correctly 


¢ Automatic/manual bootstrap of an operating system following processor halts. 
¢ Automatic/manual restart of an operating system following processor halts. 


e An interactive command language that allows the user to examine and alter 
the state of the processor 


¢ Support of various terminals and devices as the system console 


¢ Multilanguage support for displaying critical system messages and handling 
LK201 country-specific keyboards 


The remainder of this section describes in detail the functions and external 
characteristics of the KA680 firmware. 
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12.2.1 General Description 


The KA680 firmware is comprised of several major functional blocks of code. The 
halt entry code is invoked following system halts, resets, or severe errors. This 
code is responsible for saving the machine state and transferring control to the 
halt dispatcher code. The halt dispatcher code determines the nature of the 
halt, then transfers control to the appropriate subcode. The halt exit code is 
invoked whenever a transition is desired from a halted state to the running state. 
This code performs a restoration of the saved context prior to the transition. 
Figure 12-1 illustrates this, and these functions are discussed in detail in Section 
12.2.2. 


Figure 12-1 KA680 Firmware Structural Components 


Firmware 


Halt Entry Halt Dispatch Halt Exit 


ROM Based System System Console 
Diagnostics Restart Bootstrap Service 


The ROM-based diagnostics consist of an initial power-up test and a series 
of functional component diagnostics invoked by a diagnostic executive. These 
functions are described in Section 12.2.5 on powerup, and in Section 12.3 on 
diagnostics. 


Depending on the nature of the halt and the hardware context, the firmware 
attempts either an operating system restart (discussed in Section 12.2.7), a 
bootstrap operation (described in Section 12.2.6), or transitions to console I/O 
mode (covered in Section 12.2.8). 
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12.2.2 Halt Code 


The main purpose of the halt code is to save the state of the machine on halt 
entry, invoke the dispatcher, and restore the state of the machine on exit to 
program I/O mode. It is comprised of halt entry, halt dispatch, and halt exit 
codes. 


12.2.3 Halt Entry - Saving Processor State 


The entry code, residing at physical address E0040000, is executed whenever the 
KA680 halts. The value that the program counter contained when the processor 
was halted is saved in IPR 42 (PR$_SAVPC). On a powerup, the PR$_SAVPC 
register value is undefined. 


The processor will halt for a variety of reasons. The reason for the halt is stored 
in PR$_SAVPSL<13:8>(RESTART_CODE), IPR 43. A complete list of the halt 
reasons and the associated console messages can be found in Table C—1 in 
Appendix C. 


After a halt, the firmware first saves the current LED code, then writes an "E" 

to the diagnostic LEDs. This action occurs within several instructions after the 
firmware has been invoked. The intent of saving the LED code is to let the user 
know that at least some instructions have been successfully executed. 


The KA680 firmware unconditionally saves the contents of the following registers 
on any halt: 


¢ RO through R15, the general-purpose registers 

¢ PR$ SAVPSL, the saved PSL register 

¢ PR$_SCBB, the system control block base register 
¢ DLEDR, the diagnostic LED register 


Note 


The SSC programmable timer registers are not saved. In some cases, 
such as bootstrap, the timers are used by the firmware and previous 
"time" context is lost. 


Several registers are unconditionally set to predetermined values by the firmware 
on any halt, processor init, or bootstrap. This action ensures that the firmware 
itself can run and protects the board from physical damage. 


The following is a list of registers that fall into this category: 

¢ The SSC configuration register (SSCCR) 

¢ The SSC address match and mask registers (ADxMCH & ADxMSK) 
¢ The CDAL bus timeout control register (CBTCR) 

¢ The SSC timer interrupt vector registers (TIVRx) 


Whenever the halt entry code is invoked, the firmware sets the console serial line 
baud rate based on the value read from the BDR and extends the halt protection 
from 8 KB to 512KB to include all of the FEPROM. 
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12.2.4 Halt Dispatch 


The action taken by the firmware on a halt is dependent primarily on the 
following information: 


e The state of BREAK enable switch BDR<7>(HALT_ENABLE) 

¢ The state of the console program mailbox, CPMBX<1:0>(HALT_ACTION) 
¢ The user-defined halt action (SET HALT) 

¢ The halt code, PR$_SAVPSL<13:8>(RESTART_CODE) 


In general, the BREAK enable switch governs whether or not a BREAK condition 
from the console serial line is recognized by the KA680. This switch also 
determines the default action taken on a powerup or other internal halt condition. 
By default, if BREAKs are enabled, the firmware invokes the console emulation 
code. If BREAKs are disabled, the firmware attempts a recovery operation. 


The console program mailbox, CPMBX<1:0>(HALT_ACTION), is used by 
operating systems to override the BREAK enable switch. It is used to instruct the 
firmware to invoke the console service, attempt to restart the operating system, 
or reboot the system following a halt, regardless of the setting of the BREAK 
enable switch. (See Figure A-2.) 


The user-defined halt action invoked by using the SET HALT console command 
(refer to the description of the SET command in Section 12.2.9 is an alternative 
way to specify a default halt action. This feature allows users to specify 
autobooting on powerups, even when BREAKs are enabled. For HALT 
instructions and error halt conditions, it is similar in function to the console 
program mailbox but has lower precedence and is only used when the console 
program mailbox is 0. This provides the user with a mechanism to specify what 
action should be taken in the event that the operating system or user application 
does not set the console program mailbox. 


The halt (or restart) code is automatically deposited in PR$_ 
SAVPSL<13:8>(RESTART_CODE) on any halt condition. This field indicates 
the cause of the halt, and for the purpose of dispatching, collapses into three 
categories. 


02: External halts 
03: Reset/powerup 
xx: All other values—(HALT instruction and all error halts) 


Table 12—1 summarizes the action taken on all halt conditons, except external 
halts, which are described in Section 12.2.4.0.1. The actual halt dispatch state 
machine is described in detail in Section B.1 of Appendix B. 
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Table 12-1 Halt Action Summary 


BREAK User- Console 

Halt Code= Enable Defined Program 

3 Switch Halt Action Mailbox Action(s) 

T 1 0,1,3 x Diagnostics, console 

T 1 2,4 x Diagnostics, if success boot, if 
either fail console 

T 0 x x Diagnostics, if success boot, if 
either fail console 

F 1 0 0 Console 

F 0 0 0 Restart, if this fails boot, if that 
fails console 

F x 1 0 Restart, if it fails console 

F x 2 0 Boot, if it fails console 

F x 3 0 Console 

F x 4 0 Restart, if this fails boot, if that 
fails console 

F x x 1 Restart, if it fails console 

F x x 2 Boot, if it fails console 

F Console 


"T” TRUE—indicates a reset or power-up condition 
"F” FALSE—indicates a HALT instruction or error halt condition 
“x” DON’T CARE—indicates that the condition is "don’t care" 


Because the KA680 does not support battery backed-up main memory, an 
operating system restart operation is not attempted on a powerup. 


12.2.4.0.1 External Halts Several conditions can trigger an external halt and 
different actions are taken, depending on the condition. 


An external halt can be caused by one of the following conditions. 


1. 


A BREAK condition on the system console serial line, if the BREAK enable 
switch is set to “enabled.” In this case, BDR<7>(HALT_ENABLE) = 1 and the 
console code is invoked. Control-P may be established as the "BREAK" 
condition by using the SET CONTROLP ENABLE console command. 


The assertion of the BHALT line on the Q22-bus causes an external halt if 
the SCR<14>(BHALT_ENABLE) bit in the CQBIC is set. As a result, the 
console code is invoked. 


The negation of DCOK on the Q22-bus, if the SCR<7>(DCOK_ACTION) bit 
is set, causes an external halt (by default, this bit is clear). As a result, the 
console code is invoked. 


Recognition of a valid MOP BOOT message by an appropriately 
initialized SGEC, if the REMOTE_BOOT_ENABLE jumper is in place 
[BDR<31>(REMOTE_BOOT_ENABLE) = 1]. As a result, a bootstrap is 
attempted. If that fails, the console is entered. 
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Note 


The firmware does not initialize the SGEC for this operation. The 
operating system must set up the SGEC to support this feature. 


Note 


The switch labeled "RESTART" negates DCOK. The DCOK bit may also 
be negated by the DEQNA sanity timer, or any other Q22—bus module 
that chooses to implement the Q22-bus restart/reboot protocol. Because 
the SCR<7>(DCOK_ACTION) bit is cleared on powerup, the default 
consequence to deasserting DCOK is to generate a processor restart. 
Hence, pushing the "RESTART" button typically initiates a power-up 
sequence and destroys system state. 


12.2.4.1 Halt Exit - Restoring Processor State 


When the firmware exits, it uses the currently defined saved context. This context 
is initially determined by what was saved when the firmware code was invoked. 
However, this context may be modified by console commands, or automatic 
operations such as an automatic bootstrap on powerup. 


When restoring the context, the firmware will flush the CPU internal cache if 
enabled, and invalidate all translation buffer entries via the internal processor 
register PR$_TBIA, IPR 57. 


In restoring the context, the console pushes the user’s PSL and PC onto the user’s 
interrupt stack, then executes a return from exception or interrupt instruction 
(REI) from that stack. This implies that the user’s interrupt stack pointer (ISP) 
is valid before the firmware can exit. This is done automatically on a bootstrap. 
However, it is suggested that the stack pointer (SP) be set to a valid memory 
location before issuing the START or CONTINUE command. Furthermore, the 
user should validate the system control block base register (SCBB or PR$_SCBB) 
prior to executing a NEXT command, because the firmware uses the trace trap 
vector for this function. At powerup, the user ISP is set to 200 (hex) and the 
system control block base register is undefined. 
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12.2.5 Power-up 


This section describes the sequence of events that occurs on power-up. 


At power-up, the KA680 firmware performs actions that are unique to the power- 
up condition. Among these actions are the following: locating and identifying a 
console device, language query, and the diagnostic countdown. Certain actions 
are dependent on the state of the "mode" switch on the H3604-SA. The mode 
switch panel which has three settings: 


12.2.5.1 Identifying the Console Device 
After powerup, the firmware attempts to determine what type of console device 
is present so that the device may be used to display further diagnostic progress. 
Normally, this is the device attached to the console serial line cable, and the 
firmware sends the "device attributes escape sequence" (<ESC>I[c) across the 
cable. This action determines the type of terminal attached and the functions it 
supports. Terminals that do not respond to the device attributes request correctly 
are assumed to be hard copy devices. 


Once a console device has been identified, the firmware displays the KA680 
banner message, which contains the processor name, the version of the firmware, 
and the version of the VMB code as explained in Figure 12-2. 


Figure 12-2 Console Banner 


KA680-A V 4.0, VMB 2.12 


ere release of VMB 


major release of VMB 
minor release of firmware 
major release of firmware 


type of release: X — engineering release 
T — field test release 
V - volume release 


processor variant: A -— time sharing 


processor type 


The banner message contains the processor name, the version of the firmware, 
and the version of VMB. The letter code in the firmware version indicates if the 
firmware is engineering release, field test release, or volume release. The first 
digit indicates the major release number and the trailing digit indicates the minor 
release number. 


Next, if the designated console device supports DEC Multinational Character Set 
(MCS) and either the battery failed during power failure or the "mode" switch is 
set to "query," the firmware prompts for the console language. The firmware first 
displays the language selection menu shown in Figure 12-3 in Section 12.2.5.1.2. 


After the language query, the firmware invokes the ROM-based diagnostics, and 
eventually displays the console prompt. 
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12.2.5.1.1| Mode Switch Set to "Test" If the mode switch is set to "test," 

the console serial line external loopback test is executed at the end of the IPT. 
An external loopback connector should be inserted in the serial line 
connector on the H3604-SA panel prior to cycling power to invoke this 
test. The purpose of this test is to verify that the console serial line connections 
from the KA680 through the H3604-SA panel are intact. 


During this test, the firmware toggles between two states, active and passive, 
each a few seconds long and each displaying a different number on the LEDs. 


During the active state (about 3 seconds long), the LEDs are set to "6." In this 
state, the firmware reads the baud rate and mode switch, then transmits and 
receives a character sequence. If the mode switch has been moved from the "test" 
position, the firmware exits the test and continues as if on a normal powerup. 


During the passive state (about 7 seconds long), the LEDs are set to "3." 


If the firmware detects an error (parity, framing, overflow, or no characters), the 
firmware "hangs" with a "6" on the LEDs. 


12.2.5.1.2 Mode Switch Set to "Query" Ifthe mode switch is set to "query" (or 
the firmware detects that the battery failed during a power loss), the firmware 
queries the user for a language that is used for displaying critical system 
messages. 


The language selection menu is shown in Figure 12-3. 


Figure 12-3 Language Selection Menu 


1) Dansk 
2) Deutsch (Deutschland/Osterreich) 
3) Deutsch (Schweiz) 
4) English (United Kingdom) 
5) English (United States/Canada) 
6) Espafiol 
7) Frangais (Canada) 
8) Francais (France/Belgique) 
9) Francais (Suisse) 
10) Italiano 
11) Nederlands 
12) Norsk 
13) Portugués 
14) Suomi 
15) Svenska 
1 


Beeline) ee 


The user may select from one of the eleven supported languages. If no response 
is received within 30 seconds, the language defaults to English KEEP>((United 
States/Canada).) For those languages that do not have a unique keyboard, Figure 
12-3 displays supported country-specific keyboard variants in parentheses. 
Language inquiry is performed only if the console device supports DEC 
MCS. Any console device that does not support DEC MCS, such as a 
VT100, defaults to English (United States/Canada). 


After completing language inquiry, the firmware proceeds as if the mode switch 
were set to "normal," as described in Section 12.2.5.1.3. 
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12.2.5.1.3. Mode Switch Set to "Normal" If the mode selected is "normal," 
then the next step in the power-up sequence is to execute the bulk of ROM- 
based diagnostics. In addition to the message text, a "countdown" is displayed to 
indicate diagnostic test progress. A successful diagnostic countdown is shown in 
Figure 12-4. 


Figure 12-4 Normal Diagnostic Countdown 


Performing normal system tests. 

666650. 664<.263:6 62's: KO bis KO ive Dyed Owrcd tia 0 O 0 wind 4 Ged Sieve dene O liens 
SO AG AB A AG AD i Aas AS AD AL AD BON Bcd has SO neo Otc 
B47 SS BAST 2 0229 28 21 262 252424 2822 2 le 20 192% 
V8 61 es LO e315 el 4 1 Sic FO ct Tiss 0009 5.082 072.0 62 0005404 OS: 
Tests completed. 


In the case of diagnostic failures, a diagnostic register dump is performed similar 
to the one shown in Figure 12-5. The remaining diagnostics execute and the 
countdown continues. For a detailed description of the register dump, refer to 
Section 12.3. 


Figure 12-5 Abnormal Diagnostic Countdown 


Performing normal system tests. 
66..65..64..63..62..61..60..59..58..57..56..55..54..53..52..51.. 
50..49..48..47..46..45..44..43..42..41..40..39..38..37..36..35.. 
34.55 8306 325 316.. 306 295 28 ic 21 266 2956 24s 629 ce 22 oe 21 6 20 6.31904 
als Srl ay rere ogee leo ered el bs eel ere Ol 


?5F 2 OE FF 0000 0000 02 ; SUBTEST_5F_0E, DE_SGEC.LIS 


P1=00000000 P2=00000000 P3=5839FF00 P4=00000000 P5=00000000 
P6=00000000 P7=00000000 P8=00000000 P9=0000080A P10=00000003 
r0=00000054 rl=20084019 r2=00004206 r3=00000000 r4=00000000 
rS=lFFFFFFC r6=C0000003 r7=20008000 r8=00004000 EPC=00000000 
10..09..08..07..06..05..04..03.. 

Normal operation not possible. 


If the diagnostics have successfully completed and halts are enabled, the firmware 
displays the console prompt and enters "console I/O" mode. 


Figure 12-6 Console Prompt 


>>> 


If the diagnostics have successfully completed and halts are disabled, the 
firmware attempts to boot an operating system. 
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Loading system software. 

No default boot device has been specified. 
Devices: 

-DIAO (RF70) 

-DIA1 (RF70) 

-MUAO (TK70) 

-EZA0 (08-00-2B-03-82-78) 


Device? 


[EZA0]: 


(BOOT/R5:0 EZAQ) 


-EZA0 


12.2.5.2 LED Codes 


In addition to the console diagnostic countdown, a hexadecimal value is displayed 
on the diagnostic LEDs on the module and the H8604-SA panel. The purpose of 
the LED display is to improve fault isolation when there is no console terminal, 
or when the hardware is incapable of communicating with the console terminal. 
Table 12-2 lists all LED codes and the associated actions performed at powerup. 
The LED code is changed before the corresponding test or action is performed. 


Table 12-2 LED Codes 


LED 
Value 


Actions 


3) 


KoTOANwDOS Dad es 


wo wo 


Initial state on powerup, no code has executed 
Entered ROM space, some instructions have executed 
Waiting for power to stabilize (POK) 

SSC RAM, SSC registers, and ROM checksum tests 
O-bit memory, interval timer, and virtual mode tests 
FPA tests 

Backup cache, primary cache, and memory tests 
NMC, NCA, memory, and I/O interaction tests 
CQBIC (Q22-bus) tests 

Console loopback tests 

SHAC DSSI subsystem tests 

SGEC Ethernet subsystem tests 


"Console I/O" mode 
Control passed to VMB 


Control passed to secondary bootstrap 


"Program I/O" mode, control passed to operating system 
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12.2.6 Operating System Bootstrap 


Bootstrapping is the process by which an operating system loads and assumes 
control of the system. The KA680 supports bootstrap of the following operating 
systems: VAX/VMS and VAXELN. Additionally, the KA680 will boot MDM 
diagnostics and any user application image that conforms to the boot formats 
described in this section. 


On the KA680 a bootstrap occurs whenever a BOOT command is issued at 
the console or whenever the processor halts and the conditions specified in the 
Table 12-1 for automatic bootstrap are satisfied. 


12.2.6.1 Preparing for the Bootstrap 


Prior to dispatching to the primary bootstrap (VMB), the firmware initializes the 
system to a known state. The initialization sequence follows: 


I 


Check the console program mailbox "bootstrap in progress” bit 
[CPMBX<2>(BIP)]. If it is set, bootstrap fails. 


If this is an automatic bootstrap, print the message "Loading system 
software." on the console terminal. 


Set CPMBX<2>(BIP). 


Validate the page frame number (PFN) bitmap. If PFN bitmap checksum is 
invalid, then: 


a. Perform an UNJAM . 
b. Perform an INIT. 
c. Retest memory and rebuild PFN bitmap. 


Validate the boot device name. If none exists, supply a list of available devices 
and prompt user for a device. If no device is entered within 30 seconds, use 
EZAO. 


Write a form of this BOOT request including the active boot flags and boot 
device on the console: for example, "(BOOT/R5:0 DUAO)". 


Initialize the Q22—bus scatter/gather map. 
a. Set IPCR<8>(AUX_HLT). 

b. Clear IPCR<5>(LMEAE). 

Perform an UNJAM . 

Perform an INIT. 


aoe 


e. If an arbiter, map all vacant Q22—bus pages to the corresponding page in 
local memory and validate each entry if that page is "good." 


f. Set IPCR<5>(LMEAE). 


Search for a 128 KB contiguous block of good memory as defined by the PFN 
bitmap. If 128 KB cannot be found, the bootstrap fails. 


Initialize the general purpose registers. 


RO = Address of descriptor of the boot device name, or 0 if none specified 
R2 = Length of PFN bitmap in bytes 

R3 = Address of PFN bitmap 

R4 = Time of day from PR$_TODR at powerup 

R5 = Boot flags 
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R10 = Halt PC value 

R11 = Halt PSL value (without halt code and map enable) 
AP = Halt code 

SP = Base of 128 KB good memory block + 512 

PC = Base of 128 KB good memory block + 512 

R1, R6, R7, R8, RY, FP = 0 


10. Copy the VMB image from FEPROM to local memory beginning at the base 
of the 128 KB good memory block + 512. 


11. Exit from the firmware to memory-resident VMB. 


On entry to VMB, the processor is running at IPL 31 on the interrupt stack with 
memory management disabled. Also, local memory is partitioned as shown in 
Figure 12-8. 


Figure 12-8 Memory Layout Prior to VMB Entry 


: 


Potential "bad" memory 


Base 
Reserved for RPB, initial stack 
Base+512(SP,PC) 


VMB image 


256 pages for VMB 
128KB block of 
"good" memory 
Balance of 128KB block (page aligned) 


to be used for SCB, stack, 
and the secondary bootstrap. 


Unused memory 


PEN bitmap 
PFN bitmap 
(always on page boundary and 
size in pages n = (# of MB )/2 ) 
Firmware "scratch memory" 
(always 16KB) 
QMR base 


Q22-Bus Scatter/Gather Map 
(always on 32KB boundary) 


Potential "bad" memory 


Top of Memory Py 
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12.2.6.1.1 Boot Devices The KA680 firmware passes the address of a 
descriptor of the boot device name to VMB through RO. This device name used 
for the bootstrap operation is one of the following: 


¢ The local Ethernet device, if no default boot device has been specified 


¢ The default boot device specified at initial powerup or via a SET BOOT 
command 


¢ The boot device name explicitly specified in a BOOT command line 


The device name may be any arbitrary character string, with a maximum length 
of 17 characters. Longer strings cause an error message to be issued to the 
console. Otherwise, the console makes no attempt at interpreting or validating 
the device name. The console converts the string to uppercase letters, and passes 
to VMB the address of a string descriptor for the device name in RO. 


Table 12-3 correlates the boot device names expected in a BOOT command with 
the corresponding supported devices. 


Table 12-3 KA680 Supported Boot Devices 


Boot Name’ Controller Type Device Type(s) 
Disk: 
[node$]DIAn On-board DSSI RF31, RF35, RF71, RF72 
DUcn RQDX3 MSCP RD52, RD53, RD54, RX33, RX50 
KDA50 MSCP RA70, RA80, RA81, RA82, RA9O, 
RAQ2 
KFQSA MSCP RF381, RF385, RF71, RF72 
KLESI RC25 
DLen RLV12 RLO1, RLO2 
DKennn KZQSA RRD42 
Tape: 
[node$]MIAn On-board DSSI TF85, TF857 
MUcn TQK50 MSCP TK50 
TQK70 MSCP TK70 
KFQSA MSCP TF70 
KLESI TU81E 
MKcennn KZQSA TLZ04 
Network: 
EZAO On-board Ethernet — 
XQcn DELQA — 
DESQA — 


1 Boot device names consist of a 2-letter device code (minimum), followed by a single-character 
controller letter (A...Z), and terminating in a device unit number (0...65535). DSSI device names may 
optionally include a node prefix, consisting of either a node number (0...7) or a node name (a string of 
up to 8 characters), terminating in a "$" 


(continued on next page) 
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Table 12-3 (Cont.) KA680 Supported Boot Devices 


Boot Name’ Controller Type Device Type(s) 
PROM: 

PRAO MRV11 — 

PRBO On-board EPROM — 


1 Boot device names consist of a 2-letter device code (minimum), followed by a single-character 
controller letter (A...Z), and terminating in a device unit number (0...65535). DSSI device names may 
optionally include a node prefix, consisting of either a node number (0...7) or a node name (a string of 
up to 8 characters), terminating in a "$". 


Table 12-3 presents a definitive list of boot devices that the KA680 
supports. However, the KA680 will likely boot other devices that adhere 
to the MSCP standards. 


12.2.6.1.2 Boot Flags The action of VMB is qualified by the value passed to 
it in R5. Rd contains boot flags that specify conditions of the bootstrap. The 
firmware passes to VMB either the R5 value specified in the BOOT command or 
the default boot flag value specified with a SET BFLAG command. 


Figure 12—9 shows the location of the boot flags used by VMB in the boot flag 
longword and describes each flag’s function. 


Figure 12-9 VMB Boot Flags (/R5:) 


3 2 
1 8 9 6 5 4 3 0 


8 
i ee CCS 


Table 12-4 VMB Boot Flags 
Field Name Description 


<31:28> RPB$V_TOPSYS This field can be any value from 0 through F. This flag 
changes the top-level directory name for the system disks 
with multiple operating systems. For example, if TOPSYS 
is 1, the top-level directory name is [SYS1...]. This does 
not apply to network bootstraps. 


<9> RPB$V_HALT Halt during bootstrap. When this bit is set, VMB halts 
on entry to VMB before transferring control to the loaded 
image, and potentially in the loaded image. 


<8> RPB$V_SOLICT File name solicit. When this bit is set, VMB prompts the 
operator for the name of the application image file. A 
maximum of a 39-character file specification is allocated at 
RPB$T_FILE. Only 16 characters are utilized in both 
tape boot and network MOP V3 booting. 


<6> RPB$V_HEADER Image header. If this bit is set, VMB transfers control to 
the address specified by the file’s image header. If this bit 
is not set, VMB transfers control to the first location of the 
load image. 


(continued on next page) 
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Table 12—4 (Cont.) VMB Boot Flags 


Field Name Description 


<5> 


<4> 


<3> 


<0> 


RPB$V_BOOBPT Bootstrap breakpoint. If this flag is set, a breakpoint 
instruction is executed in VMB and control is transferred 
to XDELTA prior to boot. 


RPB$V_DIAG Diagnostic bootstrap. When this bit is set, 
the load image requested over the network is 
[SYSO.SYSMAINT]DIAGBOOT.EXE. 


RPB$V_BBLOCK Secondary bootstrap from bootblock. When this bit is 
set, VMB reads logical block number 0 of the boot device 
and tests it for conformance with the boot block format. 
If in conformance, the block is executed to continue the 
bootstrap. No attempt to perform a Files—11 bootstrap is 
made. 


RPB$V_CONV Conversational bootstrap. 


12.2.6.2 Primary Bootstrap, VMB 


Virtual memory boot (VMB) is the primary bootstrap for booting VAX processors. 
On the KA680, VMB is resident in the firmware and is copied into main memory 
before control is transferred to it. VMB then loads the secondary bootstrap image 
and transfers control to it. 


In certain cases, such as VAXELN, VMB actually loads the operating system 
directly. However, in this chapter, "secondary bootstrap" refers to any VMB 
loadable image. 


VMB inherits a well-defined environment and is responsible for further 
initialization. The following summarizes the operation of VMB: 


1, 


2 
3. 
4 


oO 


10. 


11. 
12. 


Initialize a 2-page SCB on the first page boundary above VMB. 
Allocate a 3-page stack above the SCB. 
Initialize the restart parameter block (RPB). Refer to Table B-2. 


Initialize the secondary bootstrap argument list. Refer to Table B—3 in 
Appendix D. 


If not a PROM boot, locate a minimum of 3 consecutive valid QMRs. 


Write "2" to the diagnostic LEDs and display "2.." on the console to indicate 
that VMB is searching for the device. 


Optionally, solicit from the console a "Bootfile: " name. 


Write the name of the boot device from which VMB will attempt to boot on 
the console (for example, "-DUAO"). 


Copy the secondary bootstrap from the boot device into local memory above 
the stack. If this fails, the bootstrap fails. 


Write "1" to the diagnostic LEDs and display "1.." on the console to indicate 


that VMB has found the secondary bootstrap image on the boot device and 
has loaded the image into local memory. 


Clear CPMBX<2>(BIP) and CPMBX<3>(RIP). 


Write "0" to the diagnostic LEDs and display "0.." on the console to indicate 


that VMB is now transferring control to the loaded image. 
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13. Transfer control to the loaded image with the following register usage: 


R5 = Transfer address in secondary bootstrap image 
R10 = Base address of secondary bootstrap memory 
R11 = Base address of RPB 

AP = Base address of secondary boot parameter block 
SP = Current stack pointer 


If the bootstrap operation fails, VMB relinquishes control to the console by 
halting with a HALT instruction. VMB makes no assumptions about 

the location of Q22-bus memory. However, VMB searches through 

the Q22-bus map registers (QMRs) for the first QMR marked "valid." 
VMB requires a minimum of 3 and a maximum of 129 contiguous "valid" 
maps to complete a bootstrap operation. If the search exhausts all map 
registers or there are fewer than the required number of "valid" maps, 

a bootstrap cannot be performed. It is reeommended that a suitable 
block of Q22-bus memory address space be available (unmapped to other 
devices) for proper operation. 


Figure 12-10 shows a sample console display of a successful automatic bootstrap. 


Figure 12-10 Successful Automatic Bootstrap 


Loading system software. 
(BOOT/R5:0 DUAQ) 


Dee 
-DUAO 
sleet 


After a successful bootstrap operation, control is passed to the secondary 
bootstrap image with the memory layout as shown in Figure 12-11. 
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Figure 12-11 Memory Layout at VMB Exit 


0 


Potential "bad" memory 


Base 


Reserved for RPB, initial stack 
Base+512(SP,PC) 


VMB image 
256 pages for VMB 
Next page 


128KB block of 
Next page+1024 (page aligned) 
Next page+2560 


Secondary bootstrap image 
(potentially exceeds block) 


Unused memory 


PFN bitmap 
PEN bitmap 
(always on page boundary and n pages 
size in pages n = (# of MB )/2 ) 
Firmware "scratch memory" 
(always 16KB) 
QMR base 


Q22-Bus Scatter/Gather Map 
(always on 32KB boundary) 


Potential "bad" memory 


Top of Memory fe a  ___ 


In the event an operating system has an extraordinarily large secondary 
bootstrap that overflows the 128 KB of "good" memory, VMB loads the remainder 
of the image in memory above the "good" block. However, if there are not enough 
contiguous "good" pages above the block to load the remainder of the image, the 


bootstrap fails. 
12.2.6.3 Device-Dependent Bootstrap Procedures 


As mentioned earlier, the KA680 supports bootstrapping from a variety of boot 
devices. The following sections describe the various device-dependent boot 
procedures. 
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12.2.6.3.1 Disk and Tape Bootstrap Procedure The disk and tape bootstrap 
supports Files—11 lookup (supporting only the ODS level 2 file structure) or 
the boot block mechanism (used in PROM boot, also). Of the standard Digital 
operating systems, VMS and ELN use the Files—11 bootstrap procedure and 
ULTRIX-32 uses the boot block mechanism. 


VMB attempts a Files—11 lookup unless the RPB$V_BBLOCK boot flag 

is set. If VMB determines that the designated boot disk is a Files—11 
volume, it searches the volume for the designated boot program, usually 
[SYSO.SYSEXE]SYSBOOT.EXE. However, VMB can request a diagnostic image 
or prompt the user for an alternate file specification (Section 12.2.6.1.2 ). If the 
boot image cannot be found, VMB fails. 


If the volume is not a Files—11 volume or the RPB$V_BBLOCK boot flag was set, 
the boot block mechanism proceeds as follows: 


1. Read logical block 0 of the selected boot device (this is the boot block). 


2. Validate that the contents of the boot block conform to the boot block format 
(Figure 12-12). 


Use the boot block to find and read in the secondary bootstrap. 


Transfer control to the secondary bootstrap image (the same as for a Files—11 
boot). 


The format of the boot block must conform to that shown in Figure 12-12. 
Figure 12-12 Boot Block Format 


low LBN high LBN 


(The next segment is also used as a PROM "signature block".) 


&P 
[oo We) 
oOo 
om 


22 11 
43 65 


Where: 


a 


1) the 18(hex) indicates this is a VAX instruction set 
2) 18(hex) + "k" = the one’s complement of "CHK" 


KA680 Firmware 12-19 


KA680 Firmware 
12.2 Firmware Capabilities 


12.2.6.3.2 PROM Bootstrap Procedure The PROM bootstrap uses a variant of 
the boot block mechanism. VMB searches for a valid PROM "signature block,” the 
second segment of the boot block defined in Figure 12-12. If PRAO is the selected 
"device," then VMB searches through Q22—bus memory on 16 KB boundaries. 

If the selected "device" is PRBO, VMB checks the top 4096-byte block of the 
FEPROM. 


At each boundary, VMB : 
1. Validates the readability of that Q22—-bus memory page 
2. Ifreadable, checks to see if it contains a valid PROM signature block 


If verification passes, the PROM image will be copied into main memory and 
VMB will transfer control to that image at the offset specified in the PROM boot 
block. If not, the next page will be tested. 


Note that it is not necessary that the boot image actually reside in 
PROM. Any boot image in Q22-bus memory space with a valid signature 
block on a 16 KB boundary is a candidate. Indeed, auxiliary bootstrap 
assumes that the image is in shared memory. 


The PROM image is copied into main memory in 127 page "chunks" until the 
entire PROM is moved. All destination pages beyond the primary 128 KB block 
are verified to make sure they are marked good in the PFN bitmap. The PROM 
must be copied contiguously, and if all required pages cannot fit into the memory 
immediately following the VMB image, the boot fails. 


12.2.6.3.3 Network Bootstrap Procedure Whenever a network bootstrap is 
selected on a KA680, the VMB code makes continuous attempts to boot from 
the network. VMB uses the DNA maintenance operations protocol (MOP) as the 
transport protocol for network bootstraps and other network operations. (Refer 
to Appendix E for a complete description of supported MOP functions during 
bootstrap.) Once a network boot has been invoked, VMB turns on the designated 
network link and repeats load attempts until either a successful boot occurs, a 
fatal controller error occurs, or VMB is halted from the operator console. 


The KA680 supports the load of a standard operating system, a diagnostic image, 
or a user-designated program via network bootstraps. The default image is the 

a standard operating system; however, a user may select an alternate image by 
setting either the RPB$V_DIAG bit or the RPB$V_SOLICT bit in the boot flag 
longword R5. Note that the RPB$V_SOLICT bit has precedence over the RPB$V_ 
DIAG bit. If both bits are set, then the solicited file is requested. (Refer to Figure 
12-9 for the usage of these bits.) 


VMB accepts a maximum of 39 characters for a file specification for 
solicited boots. However, MOP V3 only supports a 16-character file name. 
If the network server is running VMS, the following defaults apply to 
the file specification: the directory MOM$LOAD: and an extension .SYS. 
Therefore, the file specification need only consist of the file name if the 
default directory and extension attributes are used. 


The KA680 VMB uses the MOP program load sequence for bootstrapping 
the module and the MOP "dump/load" protocol type for load-related message 
exchanges. The types of MOP message used in the exchange are listed in 
Table E-1 and Table E—2 in Appendix E. 
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VMB, the requester, starts by sending a REQ PROGRAM message in the 
appropriate envelope (Table E—3 in Appendix E) to the MOP "dump/load" 
multicast address (Table E—4 in Appendix E ). It then waits for a response 
in the form of a VOLUNTEER message from another node on the network, 
the MOP load server. If a response is received, then the destination address 
is changed from the multicast address to the node address of the server. 
The same REQ PROGRAM message is retransmitted to the server as an 
acknowledge, which initiates the load. 


Next, VMB begins sending REQ_.MEM_LOAD messages in response to any of 
the following: 


— AMEM_LOAD message, while there is still more to load 
—- AMEM_LOAD w_XFER, if it is the end of the image 


— A PARAM_LOAD_w_XFER, if it is the end of the image and operating 
system parameters are required 


The "load number" field in the load messages is used to synchronize the load 
sequence. At the beginning of the exchange, both the requester and server 
initialize the load number. The requester only increments the load number 
if a load packet has been successfully received and loaded. This forms the 
acknowledge to each exchange. The server will resend a packet with a specific 
load number until it sees a request with the load number incremented. The 
final acknowledge is sent by the requester and has a load number equivalent 
to the load number of the appropriate LOAD_w_XFER message + 1. 


Because the request for load assistance is a MOP "must transact" operation, 
the network bootstrap continues indefinitely until a volunteeer is found. 

The REQ PROGRAM message is sent out in bursts of eight at 4-second 
intervals, the first four in MOP Version 4 IEEE 802.3 format and the last 
four in MOP Version 3 Ethernet format. The backoff period between bursts 
doubles each cycle from an initial value of four seconds, to eight seconds... 

up to a maximum of five minutes. However, to reduce the likelihood of many 
nodes posting requests in lock-step, a random "jitter" is applied to the backoff 
period. The actual backoff time is computed as (.75+(.5*RND(x)))*BACKOFF, 
where 0<=x<1. 
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12.2.7 Operating System Restart 


An operating system restart is the process of bringing up the operating system 
from a known initialization state following a processor halt. This procedure is 
often called restart or warmstart, and should not be confused with a processor 
restart, which results in firmware entry. 


On the KA680, a restart occurs if the conditions specified in Table 12-1 are 
satisfied. 


To restart a halted operating system, the firmware searches system memory for 
the restart parameter block (RPB), a data structure constructed for this purpose 
by VMB. (Refer to Table B—2 in Appendix B for a detailed description of this data 
structure.) If a valid RPB is found, the firmware passes control to the operating 
system at an address specified in the RPB. 


The firmware keeps a "restart in progress" (RIP) flag in CPMBX, which it uses 
to avoid repeated attempts to restart a failing operating system. An additional 
"restart in progress" flag is maintained by the operating system in the RPB. 


The firmware uses the following algorithm to restart the operating system: 
1. Check CPMBX<3>(RIP). If it is set, restart fails. 

2. Print the message "Restarting system software." on the console terminal. 
3. Set CPMBX<3>(RIP). 

4. Search for a valid RPB. If none is found, restart fails. 

5 


Check the operating system RPB$L_RSTRTFLG<0>(RIP) flag. If it is set, 
restart fails. 


Write "0" on the diagnostic LEDs. 
7. Dispatch to the restart address, RPB$L_RESTART, with : 


SP = The physical address of the RPB plus 512 
AP = The halt code 

PSL = 041F0000 

PR$_MAPEN = 0 


If the restart is successful, the operating system must clear CPMBX<3>(RIP). 


If restart fails, the firmware prints "Restart failure." on the system console. 
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12.2.7.1 Locating the RPB 
The RPB is a page-aligned control block, which can be identified by the first three 
longwords. The format of the RPB "signature" is shown in Figure Figure 12-13. 
(Refer to Table B—2 in Appendix B for a complete description of the RPB.) 


Figure 12-13 Locating the Restart Parameter Block 


RPB: +00 |physical address of the RPB 


+04 | physical address of the restart routine 


+08 | checksum of first 31 longwords of restart routine 


The firmware uses the following algorithm to find a valid RPB: 


1. Search for a page of memory that contains its address in the first longword. 
If none is found, the search for a valid RPB has failed. 


2. Read the second longword in the page (the physical address of the restart 
routine). If it is not a valid physical address, or if it is zero, return to step 1. 
The check for zero is necessary to ensure that a page of zeros does not pass 
the test for a valid RPB. 


3. Calculate the 32-bit twos-complement sum (ignoring overflows) of the first 
31 longwords of the restart routine. If the sum does not match the third 
longword of the RPB, return to step 1. 


4. A valid RPB has been found. 


12.2.8 Console Service 
By definition, the KA680 is "halted" whenever the console program is running 
and the triple angle prompt ">>>" is displayed on the console terminal. When 
the processor is halted, the firmware provides most of the services of a standard 
VAX console through the device that is designated as the system console. The 
firmware also implements several commands not defined in the VAX Architecture 
Reference Manual. For a summary of the console commands, see Table 12-16. 


12.2.8.1 Console Control Characters 
In console I/O mode, several characters have special meanings. 
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Table 12—5 Console Control Characters 


Keyboard 
Key 


Control Character 


Meaning 


RETURN 


Ctrl/A 
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Carriage Return 


Delete Character 


Control-A or F14 


Ends a command line. No action is taken on a 
command until after it is terminated by a carriage 
return. A null line terminated by a carriage 
return is treated as a valid, null command. No 
action is taken, and the console reprompts for 
input. Carriage return is echoed as carriage 
return, line feed. 


When the operator types rubout, the console 
deletes the character that the operator previously 
typed. What appears on the console terminal 
depends on whether the terminal is a video 
terminal or a hard copy terminal. 


For hard copy terminals, when a rubout is 
typed, the console echoes with a backslash 
("<backslash>"), followed by the character being 
deleted. If the operator types additional rubouts, 
the additional characters deleted are echoed. 
When the operator types a nonrubout character, 
the console echoes another backslash, followed 
by the character typed. The result is to echo 
the characters deleted, surrounding them with 
backslashes. 


For video terminals, when RUBOUT is typed, the 
previous character is erased from the screen, and 
the cursor is restored to its previous position. 


The console does not delete characters past the 
beginning of a command line. If the operator 
types more rubouts than there are characters 
on the line, the extra rubouts are ignored. Ifa 
RUBOUT is typed on a blank line, it is ignored. 


Toggle insertion/overstrike mode for command 
line editing. By default, the console powers up to 
overstrike mode. 


(continued on next page) 
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Table 12—5 (Cont.) Console Conirol Characters 


Keyboard 
Key 


Control Character 


Meaning 


Ctrl/B 


Ctri/C 


Ctri/D 


Ctri/E 
Ctrl/F 


Ctri/H 


Ctrl/O 


Ctri/Q 


Ctri/S 


Ctri/U 


Ctr/R 


BREAK 


Control-B or up_arrow 
(or down_arrow) 


Control-C 


Control-D or left_ 
arrow 


Control-E 


Control-F or right_ 
arrow 


Control-H, 
BACKSPACE or F12 


Control-O 


Control-Q 


Control-S 


Control-U 


Control-R 


BREAK 


Recall previous command(s). Command recall is 
only operable if sufficient memory is available. 
This function may then be enabled and disabled 
using the SET RECALL command. 


Causes the console to echo *C and to abort 
processing of a command. Control-C has no effect 
as part of a binary load data stream. Control-C 
reenables output stopped by Control-O. 


Moves the cursor left one position. 


Moves the cursor to the end of the line. 


Moves the cursor right one position. 
Moves the cursor to the beginning of the line. 


Causes the console to throw away transmissions 
to the console terminal until the next Control-O is 
entered. 


Control-O is echoed as “O<CR> when it disables 
output, but is not echoed when it reenables 
output. Output is reenabled if the console prints 
an error message, or if it prompts for a command 
from the terminal. 


Displaying a REPEAT command does not reenable 
output. When output is reenabled for reading 

a command, the console prompt is displayed. 
Output is also enabled by Control-S. 


Causes the output to the console terminal to 
resume. Additional control-Qs are ignored. 
Control-S and control-Q are not echoed. 


Stops output to the console terminal until control- 
Q is typed. Control-S and Control-Q are not 
echoed. 


The console echoes *‘U<CR>, and deletes the 
entire line. If Control-U is typed on an empty 
line, it is echoed, and the console prompts for 
another command. 


Causes the console to echo <CR><LF> followed by 
the current command line. This function can be 
used to improve the readability of a command line 
that has been heavily edited. 


When Control-C is typed as part of a command 
line, the console deletes the line as it does with 
Control-U. 


If the console is in console I/O mode, BREAK is 
equivalent to Control-C and is echoed as "“C". 
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Note 


If the local console is in program I/O mode and halts are disabled, BREAK 
is ignored. If the console is in program I/O mode and halts are enabled, 
BREAK causes the processor to halt and enter console I/O mode. 


Control characters are typed by pressing the character key while holding down 
the control key. 


If an unrecognized control character (ASCII code less than 32 decimal or between 
128 and 159 decimal) is typed, it is echoed as up arrow followed by the character 
with ASCII code 64 greater. For example, BEL (ASCII code 7) is echoed as "‘G", 
because capital G is ASCII code 7+64=71. When a control character is deleted 
with rubout, it is echoed the same way. After echoing the control character, the 
console processes it like a normal character. Commands with control characters 
are invalid unless they are part of a comment, and the console will respond with 
an error message. 


12.2.8.2 Console Command Syntax 
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The console accepts commands of lengths up to 80 characters. It responds to 
longer commands with an error message. The count does not include rubouts, 
rubbed out characters, or the terminating carriage return. 


Commands may be abbreviated. Abbreviations are formed by dropping characters 
from the end of a keyword, as long as the resulting keyword is still unique. Most 
commands can be uniquely expressed with their first characters. 


Multiple adjacent spaces and tabs are treated as a single space by the console. 
Leading and trailing spaces and tabs are ignored. Tabs are echoed as spaces. 


Command qualifiers can appear after the command keyword, or after any symbol 
or number in the command. A qualifier is any contiguous set of non- whitespace 
characters, and is started with a slash (ASCII code 47 decimal). 


All numbers (addresses, data, counts) are in hexadecimal. Note, though, that 
symbolic register names number the registers in decimal. The console does not 
distinguish between upper- and lowercase either in numbers or in commands; 
both are accepted. 
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12.2.8.3 Console Command Keywords 
The KA680 firmware implements a variant of the VAX console command set. 
The only commands defined in the VAX SRM and not supported by the KA680 
are MICROSTEP, LOAD, and @. The CONFIGURE, HELP, MOVE, SEARCH 
and SHOW commands have been added to the command set to facilitate system 
debugging and access to system parameters. In general, however, the KA680 
console is similar to other VAX consoles. 


Table 12-6 lists command and qualifier keywords. 


Table 12-6 Command, Parameter, and Qualifier Keywords 


Command Keywords 


Processor Control Data Transfer Console Control 
B*OOT D*EPOSIT CONF*IGURE 
C*ONTINUE E*XAMINE F*IND 

H*ALT M*OVE R*EPEAT 
I*NITIALIZE SEA*RCH SET 

N*EXT Xx SH*OW 
S*TART T*EST 
U*NJAM XDELTA 


SET & SHOW Parameter Keywords 


BO*OT BF*L(A)G DE*VICE 

DS*SI ET*HERNET HA*LT 

H*OST L*ANGUAGE M*EMORY 
Q*BUS R*ECALL RL*V12 

U*QSSP VERS*ION T*RANSLATION 


Qualifier Keywords 


Command 
Data Control Address Space Control Specific 
/B /G /IN*STRUCTION 
/W /I /NO*T 
/L /P /R5: or / 
/Q IV /RP*B or /ME*M 
IN: /M /F*ULL 
/ST*EP: /U /DU*P or 
/MA*INTENANCE 
/WR*ONG — /DS*SI or 
/U*QSSP 
/DI*SK or /T*APE 


(continued on next page) 
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Table 12-6 (Cont.) Command, Parameter, and Qualifier Keywords 


Qualifier Keywords 


Command 
Data Control Address Space Control Specific 


/SE*RVICE 


"*" indicates the minimal number of characters that are required to uniquely identify the keyword. 


A complete summary of the console commands is provided in Table 12-16 
following the command descriptions. 


12.2.8.4 Console Command Qualifiers 
All qualifers in the console command syntax are global. That is, they may appear 
in any place on the command line after the command keyword. 


All qualifiers have unique meanings throughout the console, regardless of the 
command. For example, the "/B" qualifier always means byte. 


Table 12-17 is a summary of the qualifers recognized by the KA680 console. 


12.2.8.5 Console Numeric Expression Radix Specifiers 


By default, the console treats any numeric expression used as an address or a 
datum as a hexadecimal integer. The user may override the default radix by 
using one of the specifiers listed in Table 12-7. 


Table 12-7 Console Radix Specifiers 


Form 1 Form 2 Radix 

%b Ab Binary 

%oo Ao Octal 

%d Ad Decimal 

%x AX Hexadecimal, default 


For instance, the value 19 is by default hexadecimal, but it may also be 
represented as %b11001, %o031, %d25, and %x19 (or in the alternate form as 
4b11001, “031, *d25, and *x19). 
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12.2.8.6 Command Address Specifiers 


Several commands take an address or addresses as arguments. In the context 
of the console, an address has two components, the address space, and the offset 
into that space. The console supports six address spaces: physical memory (/P 
qualifier), virtual memory (/V qualifier), general-purpose registers (/G qualifier), 
internal processor registers (/I qualifier), protected memory (/U qualifier), and the 
PSL (/M qualifier). 


The address space that the console references is inherited from the previous 
console reference, unless explicitly specified. The initial address space reference 
is physical. 


12.2.8.7 Console Symbolic Addressing 


The KA680 console supports symbolic references to addresses. A symbolic 
reference simultaneously defines the address space for a given symbol. Table 12-8 
lists the symbols that use the last referenced address and address space to 
compute the effective address. Table 12-9, Table 12-10, and Table 12—11 list the 
symbolic addresses supported by the console grouped according to address space. 


Table 12-8 Console Symbols Using Last Referenced Address 


He The last location successfully referenced in an EXAMINE or DEPOSIT 
command. 
"4" The location immediately following the last location successfully referenced 


in an EXAMINE or DEPOSIT command. 


For references to physical or virtual memory spaces, the location 
referenced is the last address, plus the size of the last reference (1 for 
byte, 2 for word, 4 for longword, 8 for quadword). For other address 
spaces, the address is the last address referenced plus one. 


The location immediately preceding the last location successfully 
referenced in an EXAMINE or DEPOSIT command. 


For references to physical or virtual memory spaces, the location 
referenced is the last address minus the size of this reference (1 for byte, 
2 for word, 4 for longword, 8 for quadword). For other address spaces, the 
address is the last address referenced minus one. 


"@" The location addressed by the last location successfully referenced in an 
EXAMINE or DEPOSIT command. 


Table 12-9 Console Symbols for General-Purpose Registers - /G 


Symbol Address Symbol Address Symbol Address Symbol Address 
RO 00 R4 04 R8 08 R12 (AP) 0C 
R1 01 R5 05 R9 09 R13 (FP) 0D 
R2 02 R6 06 R10 0A R14 (SP) OE 
R3 03 R7 07 R11 0B R15 (PC) OF 
/M - Processor Status Longword 
PSL — — — — — 
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Table 12-10 Console Symbols for Internal/External Processor Registers - /I 


Symbol Address Symbol Address Symbol Address Symbol Address 
pr$_ksp 00 pr$_pcbb 10 pr$_rxcs 20 — 30 
pr$_esp 01 pr$_scbb 11 pr$_rxdb 21 —- 31 
pr$_ssp 02 pr$_ipl 12 pr$_txcs 22 —- 32 
pr$_usp 03 pr$_astlv 13 pr$_txdb 23 — 33 
pr$_isp 04 pr$_sirr 14 —? 24 — 34 
— 05 pr$_sisr 15 — 25 — 35 
— 06 — 16 pr$_mcesr 26 — 36 
— 07 — 17 — 27 pr$_ioreset 37 
pr$_p0br 08 pr$_iccs 18 — 28 pr$_mapen 38 
pr$_p0lr 09 pr$_nicr 19 — 29 pr$_tbia 39 
pr$_plbr 0A pr$_icr 1A pr$_savpc 2A pr$_tbis 3A 
pr$_pllr 0B pr$_todr 1B pr$_savpsl 2B —- 3B 
pr$_sbr OC — 1C — 2C —- 3C 
pr$_slr 0D — 1D — 2D — 3D 
— OE — 1E — 2E pr$_sid 3E 
— OF — 1F — 2F pr$_tbchk 3F 
pr$_ecr 7D — — — —- — — 
pr$_cctl AO pr$_neoadr BO pr$_vmar DO — FO 
— Al — Bl pr$_vtag D1 — Fl 
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Table 12-10 (Cont.) Console Symbols for Internal/External Processor Registers - /l 


Symbol Address Symbol Address Symbol Address Symbol Address 
pr$_bcdecc A2 pr$_neocmd B2 pr$_vdata D2 pr$_pcadr F2 
pr$_bcetsts A3 — B3 pr$_icsr D3 — F3 
pr$_bcetidx A4 pr$_nedathi B4 —- D4 pr$_pcsts F4 
pr$_bcetag A5 — B5 — D5 — F5 
pr$_bcedsts A6 pr$_nedatlo B6 — D6 — F6 
pr$_bcedidx A7 — B7 pr$_pamode E7 — F7 
pr$_bcedecc A8 pr$_neicmd B8 — E8 pr$_pcctl F8 
pr$_cefadr AB — B9 —- E9 —- F9 
pr$_cefsts AC — BA pr$_tbadr EC —- FA 
pr$_nests AE — BB pr$_tbsts ED —- FB 
pr$_bctag 01000000 pr$_bcflush 01400000 pr$_pctag 01800000 pr$_pcdap 01C00000 
Table 12-11 Console Symbols for VAX Physical I/O Space Registers - /P 

Symbol Address Symbol Address Symbol Address Symbol Address 
qbio 20000000 qbmem 30000000 qbmbr 20 — — 

080010 
rom 20040000 —- —_- bdr 20084004 —- —- 
ser 20080000 dser 20080004 gqbear 20 dear 2008000C 
080008 

ipcrO 20001f40 ipcr1 20001f42 ipcer2 20001f44 iper3 20001f46 
ssc_ram 20140400 ssc_cr 20140010 ssc_cbtcr 20140020 ssc_dledr 20140030 
ssc_adOmat 20140130 ssc_adOmsk 20140134 ssc_adlmat 20140140 ssc_adimsk 20140144 
ssc_tcr0 20140100 ssc_tirO 20140104 ssc_tnirO 20140108 ssc_tivr0 2014010c 
ssc_tcr1 20140110 ssc_tirl 20140114 ssc_tnirl 20140118 ssc_tivr1 2014011c 
nicsr0 20008000 nicsr1 20008004 nicsr2 20008008 _nicsr3 2000800C 
nicsr4 20008010 nicsr5 20008014 nicsr6 20008018 nicsr7 2000801C 
—_—- 20008020 nicsr9 20008024 nicsr10 20008028 nicsr11 2000802C 
nicsr12 20008030 nicsr13 20008034 nicsr14 20008088 nicsr15 2000803C 
sgec_setup 20008000 sgec_txpoll 20008004 sgec_rxpoll 20008008 sgec_rba 2000800C 
sgec_tba 20008010 sgec_status 20008014 sgec_mode 20008018 sgec_sbr 2000801C 
—- 20008020 sgec_wdt 20008024 sgec_mfc 20008028 sgec_verlo 2000802C 
sgec_verhi 20008030 sgec_proc 20008034 sgec_bpt 20008038 sgec_cmd 2000803C 
shacl_sswcr 20004030 shacl_sshma 20004044 shacl_pqbbr 20004048 shacl_psr 2000404c 


(continued on next page) 
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Table 12-11 (Cont.) Console Symbols for VAX Physical I/O Space Registers - /P 


Symbol Address Symbol Address Symbol Address Symbol Address 
shacl_pesr 20004050 shacl_pfar 20004054 shacl_ppr 20004058 shacl_pmcsr 2000405C 
shacl_pcqOcr 20004080 shacl_pcqicr 20004084 shacl_pcq2cr 20004088 shacl_pcq3cr 2000408C 
shacl_pdfqer 20004090 shacl_ 20004094 shacl_psrcr 20004098 shacl_pecr 2000409C 
pmfqer 
shacl_pdcr 200040A0 shacl_picr 200040A4 shacl_pmtcr 200040A8 shacl_ 200040AC 
pmtecr 
shac2_sswcr 20004230 shac2_sshma 20004244 shac2_pqbbr 20004248 shac2_psr 2000424c 
shac2_pesr 20004250 shac2_pfar 20004254 shac2_ppr 20004258 shac2_pmcsr 2000425C 
shac2_pcqOcr 20004280 shac2_pcqlcr 20004284 shac2_pcq2cr 20004288 shac2_pcq3cr 2000428C 
shac2_pdfqer 20004290 shac2_ 20004294 shac2_psrcr 20004298 shac2_pecr 2000429C 
pmfqer 
shac2_pdcr 200042A0 shac2_picr 200042A4 shac2_pmtcr 200042A8 shac2_ 200042AC 
pmtecr 

shac_sswer 20004230 shac_sshma 20004244 shac_pqbbr 20004248 shac_psr 2000424c 
shac_pesr 20004250 shac_pfar 20004254 shac_ppr 20004258 shac_pmcsr 2000425C 
shac_pcqOcr 20004280 shac_pcqicr 20004284 shac_pcq2cr 20004288 shac_pcq3cr 2000428C 
shac_pdfqcr 20004290 shac_pmfgqer 20004294 shac_psrcr 20004298 shac_pecr 2000429C 
shac_pdcr 200042A0 shac_picr 200042A4 shac_pmtcr 200042A8 shac_pmtecr 200042AC 
nmccwb 21000110 —- —- — —- —- — 

memcon0 21018000 memconl 21018004 memcon2 21018008 memcon3 2101800c 
memcon4 21018010 memcond 21018014 memcon6 21018018 memcon7 2101801c 
memsig8 21018020 memsig9 21018024 memsig10 21018028 memsig1l1 2101802c 
memsig12 21018030 memsig13 21018034 memsig14 21018038 memsig15 2101803c 
mear 21018040 mser 21018044 nmcdsr 21018048 moamr 2101804C 
cear 21020000 ncadsr 21020004 csearl 21020008 csear2 2102000c 
cpioeal 21020010 cpioar2 21020014 ndear 21020018 —- — 
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12.2.8.8 References to Processor Registers and Memory 


The KA680 console is implemented in VAX macrocode executing from FEPROM. 
Actual processor registers cannot be modified by the console command interpreter. 
When the console is entered, the console saves the processor registers in console 
memory and all command references to them are directed to the corresponding 
saved values, not to the registers themselves. 


When the console reenters program I/O mode, the saved registers are restored 
and any changes become operative only then. References to processor memory 
are handled normally. The binary load and unload command can not reference 
the console memory pages. 


The following registers are saved by the console, and any direct reference to these 
registers will be intercepted by the console and the access will be to the saved 
copies: 


e RO...R15 - The general-purpose registers (GPRs) 

¢ PR$_IPL - The interrupt priority level register (IPL) 

¢ PR$_SCBB - The system control block base register (SCBB) 

¢ PR$_ISP - The interrupt stack pointer (ISP) 

¢ PR$_MAPEN - The memory management enable register (MAPEN) 
¢ PR$_ECR - Ebox control register (ECR) 


The following registers are also saved, yet may be accessed directly via console 
commands. Writing values to these registers may make the console inoperative. 


e PR$_SAVPC - The halt PC (SAVPC) 
e PR$_SAVPSL - The halt PSL (PSL) 


¢ ADxMCH/ADxMSK - The SSC address decode and match registers (BDMTR, 
BDMKR) 


¢ SSCCR - The SSC configuration register 
¢ DLEDR - The SSC diagnostic LED register 
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12.2.9 Console Commands 


The following sections define the commands accepted by the console when the 
KA680 is in console I/O mode. The following conventions are used to describe 
command syntax: 


Syntax Conventions 
The following conventions are used to describe command syntax: 


Table 12-12 Command Syntax 


[] Enclose optional command elements. 
{} Enclose a command element. 


Indicates a series of command elements. 


The console allows you to override the default radix by using the following 
commands: 


Table 12-13 Default Radix 


%od Decimal (for example, %d1234) 

%ox Hexadecimal (for example, %xFEEBFCEA) 
%b Binary (for example, %b1001) 

%o Octal (for example, %01070) 


The following is an example of a console EXAMINE command that specifies a 
decimal value for the /N qualifier: 


>>>EX/L/P/N:%d1023 0 
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BOOT 


BOOT 


Format 


Qualifiers 


Arguments 


Description 


BOOT [qualifier] [{boot_device}}:]] 


/R5:{boot_flags} 

Boot flags is a 32-bit hex value that is passed to VMB in R5. No interpretation 
of this value is performed by the console. Refer to Figure 12-9 for the bit 
assignments of R5. A default boot flags longword may be specified using the SET 
BFLAG command and displayed with the SHOW BFLAG command. 


/{boot_flags} 
Equivalent to the form above. 


[{boot_device}] 

The boot device name may be any arbitrary character string, with a maximum 
length of 17 characters. Longer strings cause a "VAL TOO BIG" error message 
to be issued from the console. Otherwise, the console makes no attempt at 
interpreting or validating the device name. The console converts the string to 
all uppercase, and passes to VMB a string descriptor to this device name in 
RO. A default boot device may be specified using the SET BOOT command and 
displayed with the SHOW BOOT command. The factory default is the Ethernet 
device, EZAO. 


The console initializes the processor and transfers execution to VMB. VMB 
attempts to boot the operating system from the specified device or the default 
boot device if none is specified. 


If a list of devices is specified, VMB attempts to boot from each device, in turn, 
and then transfers control to the first successfully booted image. In a list, 
network devices should always be placed last because network bootstraps only 
terminate if a fatal hardware error occurs or an image is successfully loaded. 


The console qualifies the bootstrap operation by passing a boot flags to VMB in 
R5. A more detailed description of the bootstrap process and how the default 
bootstrap device is determined is described in Section 12.2.6. 


In case either the qualifiers or the device name is absent, the corresponding 
default value is used. Explicitly stating the boot flags or the boot device overrides 
the current default value for the current boot request, but does not change the 
corresponding default value in NVRAM. 


There are three mechanisms by which the default boot device and and boot flags 
may be set. 


1. The operating system may write a default boot device and flags into the 
appropriate locations in NVRAM (Appendix A ). 


2. The user may explicitly set the default boot device and boot flags with the 
console SET BOOT and SET BFLAG commands, respectively. 
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3. The console will prompt the user for the default boot device if any of the 
following conditions are met: 


¢ The power-up mode switch is set to "query" mode. 


¢ The console detects that the battery failed; therefore, the contents of 
NVRAM are no longer valid. 


¢ The console detects that the default boot device has not been explicitly 
set by the user. Either a previous device query timed out and defaulted 
to EZAO or neither (1) nor (2) has been performed. Simply stated, the 
console will prompt the user on every powerup for a default boot device, 
until such a request has been satisfied. 


On powerup, if no default boot device is specified in NVRAM, the console issues a 
list of potential bootable devices and then queries the user for a device name. If 

no device name is entered within 30 seconds, EZAO is used. However, EZAO does 
not become the "default" boot device. 


Examples 


>>>show boot 
DUAO 

>>>show bflag 

0 

>>>b 

(BOOT/R5:0 DUAO) 


Ve 

-DUAO 

>>>bo EZA0 

(BOOT/R5:0 EZAQ) 
Dive 

-EZA0 

>>>boot/10 

(BOOT/R5:10 DUAO) 
Qed 

-DUAO 

>>>boot /r5:220 EZA0 

(BOOT/R5:220 EZA0) 
Divs 

-EZA0 


>>>boot dia0,mua0,eza0 


(BOOT/R5:0 DIAO,MUAO, EZA0) 


Dees 
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! 


! 


! 


! 


! Boot 


! Boot 


! Boot 


Boot 


using default boot flags and device. 


using default boot flags and specified device. 


using specified boot flags and default device. 


using specified boot flags and device. 


CONFIGURE 


CONFIGURE 


Format 
CONFIGURE 


Qualifiers 


None. 


Arguments 


None. 


Description 


CONFIGURE is similar to the VMS SYSGEN CONFIG utility. This feature 
simplifies system configuration by providing information that is typically 
available only with a running operating system. 


The CONFIGURE command invokes an interactive mode that permits the user to 
enter Q22—bus device names, then generates a table of Q22—bus I/O page device 
CSR addresses and device vectors. 


Examples 

>>>configure 

Enter device configuration, HELP, or EXIT 

Device,Number? help 

Devices: 

LPV11 KXJ11 DLV11Jd DZQ11 DZV11 DFA01 
RLV12 TSVO5 RXV21 DRV11W DRV11B DPV11 
DMV11 DELQA DEQNA DESQA RQDX3 KDA50 
RRD50 RQC25 KFQSA-DISK TQK50 TOQK70 TU81E 
RV20 KFQSA-TAPE KMV11 IEQ11 DHQ11 DHV11 
CXA16 CXB16 CXY08 VCB01 QVSS LNV11 
LNV21 QPSS DSV11 ADV11C AAV11C AXV11C 
KWV11C ADV11D AAV11D VCB02 QDSS DRV11J 
DRQ3B Vsv21 IBQ01 IDV11A IDV11B IDV11C 

DV11D IAV11A IAV11B MIRA ADQ32 DTCc04 

DESNA IGQl1 DIV32 KIV32 DTCN5 DTC05 
KWV32 KZQSA M7577 LNV24 M7576 DEQRA 

Numbers: 


1 to 255, default is 1 
Device,Number? kda50 
Device,Number? kfqsa 
Device is ambiguous 
Device,Number? kfqsa-disk 
Device,Number? kfqsa-tape 
Device,Number? cxy08 
Device,Number? cxal6 
Device,Number? exit 


Address/Vector Assignments 
-772150/154 KDA5SO 
-760334/300 KFQSA-DISK 
-774500/260 KFQSA-TAPE 
-760500/310 CXY08 
-760520/320 CXA16 

>>> 
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CONTINUE 


CONTINUE 


Format 
CONTINUE 


Qualifiers 


None. 


Arguments 


None. 


Description 


The processor begins instruction execution at the address currently contained in 
the program counter. Processor initialization is not performed. The console enters 
program I/O mode. Internally, the CONTINUE command pushes the user’s PC 
and PSL onto the user’s ISP, and then executes an REI instruction. This implies 
that the user’s ISP is pointing to some valid memory. 


Examples 


>>>continue 
>>> 
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DEPOSIT 


DEPOSIT 


Format 


Qualifiers 


DEPOSIT — [qualifier_list] {address} {data} [{data}...] 


/B 
The data size is byte. 


/W 
The data size is word. 


/L 
The data size is longword. 


/Q 
The data size is quadword. 


IG 
The address space is the general-purpose register set, RO through R15. The data 
size is always long. 


/I 

The address space is internal processor registers (IPRs). These are the registers 
only accessible by the MTPR and MFPR instructions. The data size is always 
long. 


/M 
The address space is the processor status longword (PSL). 


/P 
The address space is physical memory. 


IN 

The address space is virtual memory. All access and protection checking occur. 
If the access would not be allowed to a program running with the current PSL, 
the console issues an error message. Virtual space DEPOSITs cause the PTE<M> 
bit to be set. If memory mapping is not enabled, virtual addresses are equal to 
physical addresses. 


/U 

Access to console private memory is allowed. This qualifier also disables virtual 
address protection checks. On virtual address writes, the PTE<M> bit will not 

be set if the /U qualifier is present. This qualifier is not inherited, and must be 
respecified on each command. 


/N:{count} 

The address is the first of a range. The console deposits to the first address, 
then to the specified number of succeeding addresses. Even if the address is 
the symbolic address "-", the succeeding addresses are at larger addresses. 
The symbolic address specifies only the starting address, not the direction 
of succession. For repeated references to preceding addresses, use REPEAT 
DEPOSIT - <DATA>. 
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DEPOSIT 


Arguments 


Description 


Examples 


/STEP:{size} 

The number to add to the current address. Normally this defaults to the data 
size, but is overridden by the presence of this qualifier. This qualifier is not 
inherited. 


/WRONG 
The ECC bits for this data are forced to the value of 3. (ECC bits of 3 will always 
generate a double bit error.) 


{address} 
A longword address that specifies the first location into which data is deposited. 
The address can be any legal address specifier as defined in Section 12.2.8.6. 


{data} 

The data to be deposited. If the specified data is larger than the deposit data size, 
the console ignores the command and issues an error response. If the specified 
data is smaller than the deposit data size, it is extended on the left with zeros. 


[{data}] 
Additional data to be deposited (up to a maximum of six values). 


Deposits the data into the address specified. If no address space or data size 
qualifiers are specified, the defaults are the last address space and data size 
used in a DEPOSIT, EXAMINE, MOVE, or SEARCH command. After processor 
initialization, the default address space is physical memory, the default data size 
is a longword, and the default address is zero. If conflicting address space or data 
sizes are specified, the console ignores the command and issues an error response. 


>>>d/p/b/n:1FF 0 0 
>>>d/v/1/n:3 1234 5 


Clear first 512 bytes of physical memory. 


Deposit 5 into four longwords starting at 
virtual memory address 1234. 
Loads GPRs RO through R8 with -1. 


>>>d/n:8 RO FFFFFFFF 


>>>d/n:200 - 0 ! Starting at previous address, clear 513 bytes. 


>>>d/1/p/n:10/s:200 0 8 ! Deposit 8 in the first longword of 
the first 17 pages in physical memory. 
>>> 
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EXAMINE 


EXAMINE 


Format 


Qualifiers 


EXAMINE — [qualifier_list] [{address}] 


/B 
The data size is byte. 


/W 
The data size is word. 


/L 
The data size is longword. 


/Q 
The data size is quadword. 


IG 
The address space is the general-purpose register set, RO through R15. The data 
size is always long. 


| 

The address space is internal processor registers (IPRs). These are the registers 
only accessible by the MTPR and MFPR instructions. The data size is always 
long. 


/M 
The address space is the processor status longword (PSL). 


/P 

The address space is physical memory. Note that when virtual memory is 
examined, the address space and address in the response are the translated 
physical address. 


IN 

The address space is virtual memory. All access and protection checking occur. 

If the access would not be allowed to a program running with the current PSL, 

the console issues an error message. If memory mapping is not enabled, virtual 
addresses are equal to physical addresses. 


/M 
The address space and display are the PSL. The data size is always long. 


/U 

Access to console private memory is allowed. This qualifier also disables virtual 
address protection checks. This qualifier is not inherited, and must be respecified 
with each command. 


/N:{count} 

The address is the first of a range. The console deposits to the first address, 
then to the specified number of succeeding addresses. Even if the address is 
the symbolic address "-", the succeeding addresses are at larger addresses. 
The symbolic address specifies only the starting address, not the direction 
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EXAMINE 


Arguments 


Description 


of succession. For repeated references to preceding addresses, use "REPEAT 
EXAMINE - <DATA>". 


/STEP:{size} 

The number to add to the current address. Normally this defaults to the data 
size, but is overridden by the presence of this qualifier. This qualifier is not 
inherited. 


/WRONG 

ECC errors on this read access to main memory are ignored. Also, if specified, 
the ECC bits actually read are displayed in parentheses following the datum. In 
the case of quadword and octaword data, the ECC bits shown apply to the most 
significant longword only. 


/INSTRUCTION 
Disassemble and display the VAX Macro-32 instruction at the specified address. 


[{address}] 
A longword address that specifies the first location to be examined. The address 
can be any legal address specifier as defined in Section 12.2.8.6. If no address is 


wot 


specified, "+" is assumed. 


Examines the contents of the memory location or register specified by the address. 
If no address is specified, "+" is assumed. The display line consists of a single 
character address specifier, the hexadecimal physical address to be examined, and 


the examined data also in hexadecimal. 


EXAMINE uses the same qualifiers as DEPOSIT. However, the /WRONG qualifier 
will cause EXAMINEs to ignore ECC errors on reads from physical memory. 
Additionally, the EXAMINE command supports an /INSTRUCTION qualifier, 
which will disassemble the instructions at the current address. 
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Examples 


>>>ex pC 


G 0000000F FFFFFFFC 


>>>ex sp 
G 0000000E 00000 
>>>ex psl 
M 00000000 041F0 
>>>e/m 
M 00000000 041F0 
>>>e r4/n:5 
G 00000004 00000 
G 00000005 00000 
G 00000006 00000 
G 00000007 00000 
G 00000008 00000 
G 00000009 801D9 
>>>ex prS_scbb 


200 


000 


000 


000 
000 
000 
000 
000 
000 


I 00000011 2004A000 


>>>e/p 0 
P 00000000 00000 
>>>ex /ins 2004000 


000 
0 


P 20040000 11 BRB 


>>>ex /ins/n:5 200 

P 20040019 DO 
20040024 D2 
2004002F D2 
20040036 7D 
2004003D DO 

P 20040044 DB 
>>>e/ins 

P 20040048 DB 
>>> 


tw tuto 


40019 
OVL 
COML 
COML 
Oe) 
OVL 
FPR 


FPR 


20040019 


1*#20140000, @#20140000 
@#20140030, @#20140502 
S*#0E, @#20140030 

RO, @#201404B2 
1*#201404B2,R1 
S*#2A, B44 (R1) 


S*#2B,B*48 (R1) 


! Examine 


! Examine 


! Examine 


! Examine 


! Examine 


! Examine 


! Examine 


! Examine 


! Look at 


EXAMINE 


the PC. 
the SP. 
the PSL. 
PSL another way. 


R4 through R9. 


the SCBB, IPR 17. 
local memory 0. 


lst byte of EPROM. 


! Disassemble from branch. 


next instruction. 
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FIND 


FIND 


Format 


Qualifiers 


Arguments 


Description 


Examples 


FIND — [qualifier-list] 


/MEMORY 

Search memory for a page-aligned block of good memory, 128 KB in length. The 
search looks only at memory that is deemed usable by the bitmap. This command 
leaves the contents of memory unchanged. 


/RPB 

Search all physical memory for a restart parameter block. The search does not 
use the bitmap to qualifiy which pages are looked at. The command leaves the 
contents of memory unchanged. 


None. 


The console searches main memory starting at address zero for a page-aligned 
128 KB segment of good memory, or a restart parameter block (RPB). If the 
segment or block is found, its address plus 512 is left in SP (R14). If the segment 
or block is not found, an error message is issued, and the contents of SP are 
preserved. If no qualifier is specified, /RPB is assumed. 


>>>ex sp Check the SP. 
G 0000000E 00000000 
>>>find /mem 
>>>ex sp 
G 0000000E 00000200 
>>>find /rpb 
?2C FND ERR 00C00004 
>>> 


Look for a valid 128KB. 
Note where it was found. 


Check for valid RPB. 
None to be found here. 
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HALT 


HALT 


Format 
HALT 


Arguments 


None. 


Description 


This command has no effect and is included for compatibility with other consoles. 


Examples 


>>>halt ! Pretend to halt. 
>>> 
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HELP 


HELP 
Format 
HELP 
Qualifiers 
None. 
Arguments 
None. 
Description 
This command has been included to help the console operator answer simple 
questions about command syntax and usage. 
Examples 


>>>help 
Following is a brief summary of all the commands supported by the console: 


UPPERCASE denotes a keyword that you must type in 
denotes an OR condition 

[] denotes optional parameters 

<> denotes a field specifying a syntactically correct value 
denotes one of an inclusive range of integers 
denotes that the previous item may be repeated 


Valid qualifiers: 
/B /W /L /Q /INSTRUCTION 
/G /I /V /P /M 
/STEP: /N: /NOT 
/WRONG /U 
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Examples 


HELP 


Valid commands: 


BOOT 
CONF 
CONT 
DEPO 
EXAM 
FIND 
HALT 
HELP 
INIT 
OVE 
EXT 


/R5:<boot_flags> | /<boot_flags>] [<boot_device>[:]] 
IGURE 

INUE 

SIT [<qualifiers>] <address> [<datum> [<datum>]] 


INE [<qualifiers>] [<address>] 
/MEMORY | /RPB] 

IALIZE 
<qualifiers>] <address> <address> 
count ] 


REPEAT <command> 
SEARCH [<qualifiers>] <address> <pattern> [<mask> 
SET BFL(A)G <boot_flags> 

SET BOOT <boot_device> 

SET CONTROLP <0..1 | DISABLED | ENABLED> 


SET HALT <0..4 | DEFAULT | RESTART | REBOOT | HALT | RESTART_REBOOT> 


SET HOST/DUP/DSSI/BUS<0..1> <node_number> [<task> 


SET HOST/DUP/UQSSP </DISK | /TAPE> <controller_number> [<task>] 


SET 
SET 


HOST/DUP/UQSSP <physical_CSR_address> [<task> 
HOST/MAINTENANCE/UQSSP/SERVICE <controller_number> 


SET HOST/MAINTENANCE/UQSSP <physical_CSR_address> 


SET 


a 


SH 


= 


eseesssescss 


TAR 
EST 


S 
S 
S 
S 
S 
S 
S 
S 
S 
SHOW 
S 
S 
S 
S 
S 
T 
U 
X 


<a 
>>> 


>>>help 


Followin 


Valid qu 
/B / 
/G / 
/STE 
/WRO 


LANGUAGE <1..15> 


SET RECALL <0..1 | DISABLED | ENABLED> 


BFL(A)G 


LANGUAGE 
EMORY [/FULL] 
RECALL 
RLV12 

QBUS 

UQSSP 

SCSI 

TRANSLATION <physical_address> 
VERSION 
T <address> 
[<test_code> [<parameters>] ] 


JAM 


ddress> <count> 


g is a brief summary of all the commands supported by the console: 


UPPERCASE denotes a keyword that you must type in 
denotes an OR condition 

[] denotes optional parameters 

<> denotes a field specifying a syntactically correct value 
denotes one of an inclusive range of integers 
denotes that the previous item may be repeated 


alifiers: 

W/L /Q /INSTRUCTION 
I /V /P /M 

P: /N: /NOT 

NG /U 
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HELP 


Valid commands: 
BOOT [[/R5:]<boot_flags>] [<boot_device>] 
CONFIGURE 
CONTINUE 
DEPOSIT [<qualifiers>] <address> <datum> 
[<datum>...] 
EXAMINE [<qualifiers>] [<address>] 
FIND [/MEMORY | /RPB] 
HALT 
HELP 
INITIALIZE 
OVE [<qualifiers>] <address> <address> 
EXT [<count>] 
REPEAT <command> 
SEARCH [<qualifiers>] <address> <pattern> 
[<mask>] 
SET BFLG <boot_flags> 
SET BOOT <boot_device> 
SET CONTROLP <0..1 | DISABLED | ENABLED> 
SET HALT <0..4 | DEFAULT | RESTART | REBOOT | HALT | RESTART_REBOOT> 
SET HOST/DUP/DSSI/BUS:<0..1> <node_number> 
[<task>] 
SET HOST/DUP/UQSSP </DISK | /TAPE> <controller_number> 
[<task>] 
SET HOST/DUP/UQSSP <physical_CSR_address> [<task>] 
SET HOST/MAINTENANCE/UQSSP/SERVICE <controller_number> 
SET HOST/MAINTENANCE/UQSSP <physical_CSR_address> 
SET LANGUAGE <1..15> 
SET RECALL <0..1 | DISABLED | ENABLED> 
iOW BFLG 
7 BOOT 
7 CONTROLP 
DEVICE 
OW DSSI 
OW ETHERNET 
HOW HALT 
OW 
0) 


) 
fe) 
HO 
0) 


a 


LANGUAGE 
iOW MEMORY [/FULL] 


1OW QBUS 
7 RECALL 
1OW RLV12 


0) 
0) 
©) 
OW SCSI 

HOW TRANSLATION <physical_address> 
1OW UQSSP 

HOW VERSION 

TART <address> 

EST [<test_code> [<parameters>] ] 
JAM 

<address> <count> 
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INITIALIZE 


INITIALIZE 


Format 
INITIALIZE 


Qualifiers 


None. 


Arguments 


None. 


Description 


A processor initialization is performed. The following registers are initialized, as 
specified in the VAX Architecture Standard. 


PSL — 041F0000 


IPL — 1F 

ASTLVL — 4 

SISR — 0 

ICCS — bits <6> and <0> are clear, the rest are unpredictable 
RXCS — 0 

TXCS — 80 

MAPEN — 0 


CPU cache — flushed 

instruction buffer — unaffected 

console previous reference — longword, physical, address 0 
TODR — unaffected 

main memory — unaffected 

general registers — unaffected 

halt code — unaffected 

bootstrap in progress flag — unaffected 

internal restart in progress flag — unaffected 


The KA680 firmware performs the following additional initialization: 


The CDAL bus timer is initialized. 

The address decode and match registers are initialized. 

The programmable timer interrupt vectors are initialized. 

The BDR registers are read to determine the baud rate, and then the SSCCR 
is configured accordingly. 

All error status bits are cleared. 


Examples 


>>>init 
>>> 
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MOVE 


MOVE 


Format 


Qualifiers 


MOVE — [qualifier-list] {src_address} {dest_address} 


/B 
The data size is byte. 


/W 
The data size is word. 


/L 
The data size is longword. 


/Q 
The data size is quadword. 


/P 
The address space is physical memory. 


IN 

The address space is virtual memory. All access and protection checking occur. 
If the access would not be allowed to a program running with the current PSL, 
the console issues an error message. Virtual space MOVEs cause the destination 
PTE<M> bit to be set. If memory mapping is not enabled, virtual addresses are 
equal to physical addresses. 


/U 

Access to console private memory is allowed. This qualifier also disables virtual 
address protection checks. On virtual address writes, the PTE<M> bit will not 

be set if the /U qualifier is present. This qualifier is not inherited, and must be 
respecified on each command. 


/N:{count} 

The address is the first of a range. The console deposits to the first address, 
then to the specified number of succeeding addresses. Even if the address is 
the symbolic address "-", the succeeding addresses are at larger addresses. 
The symbolic address specifies only the starting address, not the direction of 
succession. 


/STEP:{size} 

The number to add to the current address. Normally this defaults to the data 
size, but is overriden by the presence of this qualifier. This qualifier is not 
inherited. 


/WRONG 

On reads, ECC errors on the access of data in main memory are ignored. On 
writes, the ECC bits for this data are forced to the value of 3. (ECC bits of 3 will 
always generate a double bit error.) 
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Arguments 


Description 


Examples 


MOVE 


{src_address} 
A longword address that specifies the first location of the source data to be copied. 


{dest_address} 

A longword address that specifies the destination of the first byte of data. These 
addresses may be any legal address specifier as defined in Section 12.2.8.6. If no 
address is specified, "+" is assumed. 


The console copies the block of memory starting at the source address to a block 
beginning at the destination address. Typically, this command is used with the 
/N: qualifier to transfer large blocks of data. The destination will correctly reflect 
the contents of the source, regardless of the overlap between the source and the 
data. 


The MOVE command actually performs byte, word, longword, and quadword 
reads and writes as needed in the process of moving the data. Moves are 
supported for the physical and virtual address spaces only. 


>>>ex /n:4 0 ! Observe destination. 
P 00000000 00000000 
P 00000004 00000000 
P 00000008 00000000 
P 0000000C 00000000 
P 00000010 00000000 
>>>ex /n:4 200 ! Observe source data. 
P 00000200 58DD0520 
P 00000204 585K04C1 
P 00000208 O0FF8FBB 
P 0000020C 5208A8D0 
P 00000210 540CA8DE 
>>>move /n:4 200 0 ! Move the data. 
>>>ex /n:4 0 ! Observe the destination. 
P 00000000 58DD0520 
P 00000004 585K04C1 
P 00000008 O0FF8FBB 
P 0000000C 5208A8D0 
P 00000010 540CA8DE 
>>> 
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NEXT 


NEXT 


Format 
NEXT — {count} 


Qualifiers 


None. 


Arguments 


{count} 
A value representing the number of macroinstructions to execute. 


Description 


The NEXT command causes the processor to "step" the specified number of 
macroinstructions. If no count is specified, "single-step" is assumed. The console 
then enters "Spacebar Step Mode". In this mode, subsequent spacebar strokes 
initiate single steps and a carriage return forces a return to the console prompt. 


The console uses the trace and trace pending bits in the PSL, and the SCB trace 
pending vector, to implement the NEXT function. This creates the following 
restrictions on the usage of the NEXT command: 


¢ Ifmemory management is enabled, the NEXT command works if and only if 
the first page in SSC RAM is mapped somewhere in SO (system) space. 


¢ The NEXT command, due to the instructions executed in implementation, 
does not work where time-critical code is being executed. 


¢ The NEXT command elevates the IPL to 31 for long periods of time 
(milliseconds) while single-stepping over several commands. 


¢ Unpredictable results occur if the macroinstruction being stepped over 
modifies the SCBB, or the trace trap entry. This means that the NEXT 
command cannot be used in conjunction with other debuggers. This also 
implies that the user should validate PR$_SCCB before using the NEXT 
command. 
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Examples 


>>>dep 1000 50D650D4 
>>>dep 1004 125005D1 
>>>dep 1008 O0OFE11F9 


>>>ex /instruction /n:5 1000 


P 00001000 D4 CLRL 
P 00001002 D6 INCL 
P 00001004 D1 CMPL 
P 00001007 12 BNEQ 
P 00001009 11 BRB 


P 0000100B 00 HALT 
>>>dep pr$_scbb 200 
>>>dep pce 1000 
>>> 
>>>n 

P 00001002 D6 INCL 

P 00001004 D1 CMPL 

P 00001007 12 BNEQ 

P 00001002 D6 INCL 
>>>n 5 

P 00001004 D1 CMPL 

P 00001007 12 BNEQ 
P 00001002 D6 INCL 

PL 
EQ 


P 00001004 DIC 
P 00001007 12 BN 
>>>n 7 


P 00001002 D6 INCL 
P 00001004 D1 CMPL 
P 00001007 12 BNEQ 
P 00001002 D6 INCL 
P 00001004 Dl CMPL 
P 00001007 12 BNEQ 
P 00001009 11 BRB 
>>>n 


P 00001009 11 BRB 
>>> 


RO 
RO 
S*#05,R0 
00001002 
00001009 


RO 
S*#05,R0 
00001002 
RO 


S*#05,R0 
00001002 


S*#05,R0 


S*#05,R0 
00001002 
00001009 


00001009 


NEXT 


! Create a simple program. 


! List it. 


! Set up a user SCBB... 


...and the PC. 


! Single step... 
! SPACEBAR 

! SPACEBAR 

! SPACEBAR 

! CR 


...or multiple step the program. 
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REPEAT 


REPEAT 
Format 
REPEAT = {command} 
Qualifiers 
None. 
Arguments 
{command} 
Description 
The console repeatedly displays and executes the specified command. The 
repeating is stopped by the operator typing Control-C. Any valid console command 
can be specified for the command with the exception of the REPEAT command. 
Examples 
>>>repeat ex pr$_todr ! Watch the clock. 
0000001B 5AFE78CE 
0000001B 5AFE78D1 
I 0000001B 5AFE78FD 
0000001B 5AFE7900 
0000001B 5AFE7903 
0000001B 5AFE7907 
0000001B 5AFE790A 
0000001B 5AFE790D 
0000001B 5AFE7910 
0000001B 5AFE793C 
I 0000001B 5AFE793F 
0000001B 5AFE7942 
0000001B 5AFE7946 
0000001B 5AFE7949 
0000001B 5AFE794C 
0000001B 5AFE794F 
0000001B 5*C 
>>> 
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SEARCH 


SEARCH 


Format 


Qualifiers 


SEARCH  [qualifier_list] {address} {pattern} [{mask}] 


/B 
The data size is byte. 


/W 
The data size is word. 


/L 
The data size is longword. 


/Q 
The data size is quadword. 


/P 

The address space is physical memory. Note that when virtual memory is 
examined, the address space and address in the response are the translated 
physical address. 


IN 

The address space is virtual memory. All access and protection checking occur. 

If the access would not be allowed to a program running with the current PSL, 

the console issues an error message. If memory mapping is not enabled, virtual 
addresses are equal to physical addresses. 


/U 

Access to console private memory is allowed. This qualifier also disables virtual 
address protection checks. This qualifier is not inherited, and must be respecified 
with each command. 


/N:{count} 

The address is the first of a range. The first access is to the address specified, 
then subsequent accesses are made to succeeding addresses. Even if the address 
is the symbolic address "-", the succeeding addresses are at larger addresses. 
The symbolic address specifies only the starting address, not the direction of 
succession. 


/STEP:{size} 

The number to add to the current address. Normally this defaults to the data 
size, but is overridden by the presence of this qualifier. This qualifier is not 
inherited. 


/WRONG 
ECC errors on read accesses to main memory are ignored. 


/NOT 
Inverts the sense of the match. 
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SEARCH 


Arguments 


Description 


{start_address} 

A longword address that specifies the first location subject to the search. This 
address can be any legal address specifier as defined in Section 12.2.8.6. If no 
address is specified, "+" is assumed. 


{pattern} 
The target data. 


[{mask}] 
A longword containing the bits in the target that are to be "masked" out. 


The SEARCH command finds all occurrences of a pattern, and reports the 
addresses where the pattern was found. If the /NOT qualifier is present, all 
addresses where the pattern did not match are reported. 


The command accepts an optional mask that indicates don’t care bits. For 
example, to ignore bit 0 in the comparison, specify a mask of 1. The mask, if not 
present, defaults to 0. 


Conceptually, a match condition occurs if the following condition is true: 


(pattern AND NOT mask) EQUALS (data AND NOT mask) 


where: pattern -- is the target data. 
mask -- is the optional don’t care bitmask (which defaults to 0). 
data -- is the data (byte, word, long, quad) at the current address. 


The command reports the address if the match condition is true, and there is no 
/NOT qualifier, or if the match condition is false and there is a /NOT qualifier. 
Stating this in a tabular form: 


/NOT Qualifier Match Condition Action 
absent true report address 
absent false no report 
present true no report 
present false report address 


The address is advanced by the size of the pattern (byte, word, long, or quad), 
unless overridden by the /STEP qualifier. 
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Examples 


>>>dep /p/1/n:1000 0 0 


>>> 


>>>dep 300 12345678 


SEARCH 


! Clear some memory. 


! Deposit some "Search" data. 


>>>dep 401 12345678 
>>>dep 502 87654321 


>>> 


>>>search /n: 


P 00000300 
P 00000401 


>>>search /n: 


P 00000300 


>>>search /n: 


P 00000300 
P 00000400 
P 00000404 
P 00000500 
P 00000504 


>>>search /n: 


P 00000502 
P 00000503 
P 00000504 
P 00000505 


>>>search /n: 


P 00000303 
P 00000404 


>>>search /n: 


1000 /st:1 0 12345678 ! Search for all occurrences... 


12345678 ! ...of 12345678 on any byte... 
12345678 ! ...boundary. 

1000 0 12345678 ! Then try on longword... 
12345678 ! ,..boundaries. 

1000 /not 0 0 ! Search for all non-zero... 
12345678 ! ,..longwords. 

34567800 

00000012 

43210000 

00008765 

1000 /st:1 0 1 FFFFFFFE ! Search for "odd" longwords... 
87654321 ! ...on any boundary. 

00876543 

00008765 

00000087 

1000 /b 0 12 ! Search for all occurrences... 
12 ! ...of the byte 12. 

12 


1000 /st:1 /w 0 FE11 ! Search for all words which... 


>>> ! ...could be interpreted as... 
>>> ! ...a "spin" (10$: brb 10S). 
>>> ! Note, none found. 
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SET 


SET 


Format 


Qualifiers 


Arguments 


Description 


Parameters 


SET {parameter} {value} 


Depends on the parameters used 


None. 


Sets the indicated console parameter to the indicated value. The following are 
console parameters and their acceptable values: 


BFL(A)G 
Sets the default R5 boot flags. The value must be a hexadecimal number of up to 
8 hex digits. 


BOOT 
Sets the default boot device. The value must be a valid device name or device list 
as specified in Section 12.2.9, Console Commands (on the BOOT command). 


CONTROLP 

Sets Control-P as the console halt condition, instead of a BREAK. Values of 
1 or ENABLED set Control-P recognition. Values of 0 or DISABLED set 
BREAK recognition. In either case, the setting of the BREAK Enable switch 
will determine whether or not a halt will occur. 


HALT 

Sets the user-defined halt action. Acceptable values are 0 through 4 or the ordinal 
keywords DEFAULT, RESTART, REBOOT, HALT, and RESTART_REBOOT. Refer 
to Table 12-1 for usage. 


HOST 

Invokes the DUP or MAINTENANCE driver on the selected node. Only SET 
HOST /DUP accepts a value parameter. The hierarchy of the SET HOST 
qualifiers listed below suggests the appropriate usage. Each qualifier only 
supports the additional qualifiers at levels below it. 


/DUP 

Uses the DUP protocol to examine/modify parameters of a device on either of the 
DSSI buses or the Q22-bus. The optional value for SET HOST /DUP is a "task" 
name for the selected DUP driver to execute. 
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SET 


Note 


The KA680 DUP driver only supports "SEND DATA IMMEDIATE" 
messages, and those devices that also support them. 


/BUS 
Selects the desired KA680 DSSI bus. A value of 0 selects DSSI bus 0 (internal 
backplane bus). A value of 1 selects DSSI bus 1 (external console module bus). 


/DSSI Node 
Selects the DSSI node, where "node" is a number from 0 to 7. 


/UQSSP 
Selects the Q22—-bus device using one of the following three methods. 


Woo 


/DISK n — Specifies the disk controller number, where "n" is from 0 to 
255. (The resulting fixed address for n=0 is 20001468 and the floating 
rank for n>0 is 26.) 

/TAPE n — Specifies the tape controller number, where "n" is from 0 
to 255. (The resulting fixed address for n=0 is 20001940 and the floating 
rank for n>0 is 30.) 

csr_address — Specifies the Q22—bus I/O page CSR address for the 
device. 


/MAINTENANCE 

Uses the MAINTENANCE protocol to examine/modify KFQSA EEPROM 
configuration parameters. Note that SET HOST /MAINTENANCE does not 
accept a "task" value. 


/UQSSP — 
/SERVICE n — Specifies the KFQSA controller number "n" of a KFQSA 


in service mode, where "n" is from 0 to 3. (The resulting fixed address of 
a KFQSA in service mode is 20001910+4*n.) 
csr_address — Specifies the Q22—bus I/O page CSR address for the 


KFQSA. 


LANGUAGE 

Sets console language and keyboard type. If the current console terminal does not 
support the Digital Multinational Character Set (MCS), then this command has 
no effect and the console remains in English message mode. Acceptable values 
are 1 through 15 and have the following meaning: 


1) Dansk 

2) Deutsch (Deutschland/Osterreich) 
3) Deutsch (Schweiz) 

4) English (United Kingdom) 

5) English (United States/Canada) 
6) Espanol 

7) Francais (Canada) 

8) Frangais (France/Belgique) 

9) Francais (Suisse) 

10) Italiano 

11) Nederlands 

12) Norsk 

13) Portugués 
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SET 


Sets command recall state to either ENABLED (1) or DISABLED (0). 


14) Suomi 
15) Svenska 
RECALL 
Arguments 
None. 
Examples 
>>> 


>>>set bflag 220 


>>> 


>>>set boot EZA0 


>>> 


>>>set controlp disabled 


>>> 


>>>set halt reboot 


>>> 


>>>set host /dup/dssi/bus:1 0 
Starting DUP server... 


Copyright 
DRVEXR V1. 
DRVTST V1. 
HISTRY V1. 
ERASE V1. 
PARAMS V1. 
DIRECT V1. 


ee eeten=) 


D 


UUUUY 


DSSI Bus 1 Node 0 (SUSAN) 
© 1990 Digital Equipment Corporation 


5-JUL-1990 15:33:06 


5-JU 
5-JU 
5-JU 
5-JU 
5-JU 


End of directory 


Task Name? params 
Copyright © 1990 Digital Equipment Corporation 


PARAMS> stat path 


ID Path Bl 


WNO BE DAO 
aS) 
w 


PARAMS> exit 


Exiting... 


Task Name? 


Ock 


11ECC 
11FD0 
120D4 
121D8 
122DC 
123E0 
12484 


L-1990 15:33:06 
L-1990 15:33:06 
L-1990 15:33:06 
L-1990 15:33:06 
L-1990 15:33:06 


Remote Node DGS_S 


Internal Path 


KFQSA 
KAREN 
WILMA 
BETTY 
DSSI1 
3 


Stopping DUP server... 


>>> 


>>>set host /dup/dssi/bus 
Starting DUP server... 


DSSI Bus 1 Node 0 (SUSAN) 
Copyright © 1990 Digital 


PARAMS> show node 
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KFX V1.0 
RFX V101 
RFX V101 
RFX V101 
VMS V5.0 
VMB BOOT 


e+ 4S SS SS 


:1 0 params 


Equipment Corporation 


DGS_R 


oO OCOCCOO 


MSGS_S 


MSGS_R 


Parameter Current 

NODENAME SUSAN RF30 
PARAMS> show allclass 

Parameter Current 

ALLCLASS 1 

PARAMS> exit 

Exiting... 


Stopping DUP server... 

>>> 

>>>set host /maint/ugssp 20001468 
UQSSP Controller (772150) 


Default 


SET 


Enter SET, CLEAR, SHOW, HELP, EXIT, or QUIT 


Node CSR Address Model 
0 772150 21 
il 760334 21 
4 760340 21 
5 760344 21 
' KFQSA ------ 
? help 
Commands: 


SET <node> /KFQSA 
SET <node> <CSR_address> <model> 
CLEAR <node> 
SHOW 
HELP 
EXIT 
QUIT 
Parameters: 
<node> 
<CSR_address> 
<model> 
? set 6 /kfqsa 
? show 
Node CSR Address Model 
0 772150 21 
1 760334 21 
4 760340 21 
5 760344 21 
6°. ‘S=SSs= KFQSA ------ 


Programming the KFQSA... 
>>> 

>>>set language 5 

>>> 

>>>set recall 1 

>>> 


set KFQSA DSSI node number 
enable a DSSI device 
disable a DSSI device 

show current configuration 
print this text 

program the KFQSA 

don’t program the KFQSA 


0 to 7 


760010 to 777774 
21 (disk) or 22 (tape) 
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SHOW 


SHOW 


Format 


Qualifiers 


Parameters 


SHOW {parameter} 


Depends on the specific parameter. 


BFL(A)G 
Shows the default R5 boot flags. 


BOOT 
Shows the default boot device. 


CONTROLP 
Shows the current state of Control-P halt recognition, either ENABLED or 
DISABLED. 


DEVICE 
Shows a list of all devices in the system. 


HALT 

Shows the user-defined halt action. One of the following keywords are displayed: 
DEFAULT, RESTART, REBOOT, HALT, or RESTART_REBOOT. Refer to 

Table 12-1 for usage. 


DSSI 

Shows the status of all nodes that can be found on the DSSI busses. For each 
node on the DSSI bus, the console displays the node number, the node name, 
and the boot name and type of the device, if available. The command does not 
indicate the "bootability" of the device. 


The node that issues the command reports a node name of "*". 


The device information is obtained from the "media type" field of the MSCP 
command GET UNIT STATUS. In case the node is not running or is not capable 
of running an MSCP server, then no device information is displayed. 


ETHERNET 
Shows the hardware Ethernet address for all Ethernet adapters that can be 
found. Displays as blank if no Ethernet adapter is present. 


LANGUAGE 
Shows the console language and keyboard type. Refer to the corresponding SET 
LANGUAGE command for the meaning. 


MEMORY 
Shows main memory configuration on a board-by-board basis. Also reports the 
addresses of bad pages, as defined by the bitmap. 


/FULL 
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Qualifiers 


SHOW 


Shows the normally inaccessible areas of memory, such as the PFN bitmap 
pages, the console scratch memory pages, and the Q22-bus scatter/gather 
map pages. 


QBUS 

Show all Q22-bus I/O addresses that respond to an aligned word read. For each 
address, the console displays the address in the VAX I/O space in hex, the address 
as it would appear in the Q22-bus I/O space in octal, and the word data that was 
read in hex. 


This command may take several minutes to complete, so the user may want to 
issue a Control-C to terminate the command. The command disables the scatter 
/gather map for the duration of the command. 


RECALL 
Shows the current state of command recall, either ENABLED or DISABLED. 


RLV12 
Shows all RLO1 and RLO2 disks that appear on the Q22—bus. 


scsl 
Shows any SCSI devices in the system. 


TRANSLATION 

Shows any virtual addresses that map to the specified physical address. The 
firmware uses the current values of page table base and length registers to 
perform its search (it is assumed that page tables have been properly built). 


UQSSP 

Shows the status of all disks and tapes that can be found on the Q22-bus that 
support the UQSSP protocol. For each such disk or tape on the Q22-bus, the 
console displays the controller number, the controller CSR address, and the boot 
name and type of each device connected to the controller. The command does not 
indicate the "bootability" of the device. 


The device information is obtained from the "media type" field of the MSCP 
command GET UNIT STATUS. In case the node is not running or is not capable 
of running an MSCP server, then no device information is displayed. 


VERSION 
Show the current version of the firmware. 


On a per parameter basis. 
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SHOW 


Arguments 


None. 


Description 


Displays the console parameter indicated. 


Examples 


>>> 
>>>show bflag 
00000220 

>>> 

>>>show boot 

EZAO 

>>> 

>>>show device 

DSSI Bus 0 Node 7 (*) 


DSSI Bus 1 Node 0 (SUSAN) 
-DIAO (RF30) 


DSSI Bus 1 Node 1 (KAREN) 
-DIA1 (RF30) 


S 
D 
DSSI Bus 1 Node 4 (WILMA) 
-DIA4 (RF30) 
S 
D 


DSSI Bus 1 Node 5 (BETTY) 
-DIA5 (RF30) 


DSSI Bus 1 Node 6 (*) 
DSSI Node 6 (KFQSA) 


SCSI Adapter 0 (761300), SCSI ID 7 
-DKA100 (DEC RZ31 (C) DEC) 
-DKA300 (MAXTOR XT-8000S) 

UQSSP Disk Controller 0 (772150) 
-DUAO (RF30) 

UQSSP Disk Controller 1 (760334) 
-DUB1 (RF30) 

UQSSP Disk Controller 2 (760340) 
-DUC3 (RF30) 

UQSSP Disk Controller 3 (760344) 
-DUD4 (RF30) 

Ethernet Adapter 

-EZAQ (08-00-2B-03-82-78) 


>>> 
DSSI Bus 0 Node 7 (*) 


DSSI Bus 1 Node 0 (SUSAN) 
-DIAO (RF30) 


DSSI Bus 1 Node 1 (KAREN) 
-DIA1 (RF30) 


DSSI Bus 1 Node 4 (WILMA) 
-DIA4 (RF30) 
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DSSI Bus 1 Node 5 (BETTY) 
-DIA5 (RF30) 


DSSI Bus 1 Node 6 (*) 
DSSI Node 6 (KFQSA) 


<>>>show ethernet 
Ethernet Adapter 

-EZA0 (08-00-2B-03-82-78) 
>>> 

>>>show halt 

Reboot 

>>>show language 


English (United States/Canada) 


>>> 
>>>show memory 


SHOW 


Memory 0: 00000000 to OO3FFFFF, 4MB, 0 bad pages 


Total of 4MB, 0 bad pages, 98 reserved pages 


>>> 
>>>show memory /full 


Memory 0: 00000000 to OO3FFFFF, 4MB, 0 bad pages 


Total of 4MB, 0 bad pages, 98 reserved pages 


Memory Bitmap 


-003F3C00 to O03F3FFF, 2 pages 


Console Scratch Area 


-003F4000 to O03F7FFF, 32 pages 


Qbus Map 
-003F8000 to OO3FFFFF, 64 


Scan of Bad Pages 

>>> 

>>>show qhbus 

Scan of Qbus I/O Space 


-200000DC (760334) = 0000 
-200000DE (760336) = OAA0 
-200000E0 (760340) = 0000 
-200000E2 (760342) = OAA0 
-200000E4 (760344) = 0000 
-200000E6 (760346) = OAA0 
-20001468 (772150) = 0000 
-2000146A (772152) = OAAO 
-20001F40 (777500) = 0020 


pages 


(300) 
(304) 
(310) 
(154) 


(004) 


RQDX3/KDA50/RRD50/RQC25/KFQSA-DISK 
ROQDX3/KDA50/RRD50/RQC25/KFQSA-DISK 
ROQDX3/KDA50/RRD50/RQC25/KFQSA-DISK 
ROQDX3/KDA50/RRD50/RQC25/KFQSA-DISK 


IPCR 
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SHOW 


Scan of Qbus Memory Space 

>>> 

>>>show rlvl2 

>>> 

>>>show scsi 

SCSI Adapter 0 (761300), SCSI ID 7 
-DKA100 (DEC R231 (C) DEC) 
-DKA300 (MAXTOR XT-8000S) 

>>> 

>>>show translation 1000 

V 80001000 

>>> 
>>>show ugqssp 

UQSSP Disk Controller 0 (772150) 
-DUAO (RF30) 


UQSSP Disk Controller 1 (760334) 
-DUB1 (RF30) 


UQSSP Disk Controller 2 (760340) 
- (RF30) 


UQSSP Disk Controlle 
(RF30) 


K 


3 (760344) 


>>> 
>>>show version 
KA680 V4.0, VMB 2.13 
>>> 
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START 


START 
Format 
START _ [{address}] 
Qualifiers 
None. 
Arguments 
[{address}] 
The address at which to begin execution. This is loaded in the user’s PC. 
Description 
The console starts instruction execution at the specified address. If no address is 
given, the current PC is used. If memory mapping is enabled, macroinstructions 
are executed from virtual memory, and the address is treated as a virtual 
address. The START command is equivalent to a DEPOSIT to PC followed by a 
CONTINUE. No INITIALIZE is performed. 
Examples 


>>>start 1000 
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TEST 


TEST 
Format 
TEST _ [{test_number} [{test_arguments}]] 
Qualifiers 
None. 
Arguments 
{test_number} 
A 2-digit hexadecimal number specifying the test to be executed. 
{test_arguments} 
Up to five additional test arguments. These arguments are accepted but no 
meaning is attached to them by the console. For the interpretation of these 
arguments, consult the test specification for the individual test. 
Description 
The console invokes a diagnostic test program specified by the test number. If a 
test number of 0 is specified, the power-up script is executed. The console accepts 
an optional list of up to five additional hexadecimal arguments. 
A more detailed explanation of the diagnostics may be found in Section 12.3. 
Examples 
>>> 
>>>unjam ! Use UNJAM and INIT to ensure a consistent state. 
>>>init ! Warning...this has the same effect as a powerup! 
>>> ! Execute the power-up diagnostic script. 
>>>test 0 


6.65.69 2°644.4:63'5. 62% 611660. 591. 08 40a DOO OAs Osos 02a. lags 
9049s AB AT 46 oe 4 44 54 B42 AT 54056395038 cod Tee O ced 0'e 
SA 8S eS cB le GOO S20 pe Opes see AOe PLO pode D onl ones Leis AOSD Ss 
Lit Mal 6.2 Cony Atay Ne TL tO. 00 90 08 Oe 064s Oba 04 M0 3a. 
>>> 

>>> ! Show the diagnostic state. 

>>> 

>>>t fe 


Bitmap=01FF2000, Length=00002000, Checksum=FFFF, Busmap=01FF8000 
Test_number=00, Subtest=00, Loop_Subtest=00, Error_type=00 
Error_vector=0000, Severity=02, Last_exception_PC=00000000 
Total_error_count=0005, Led_display=0C, Console_display=03, save_mchk_code=00 
parameter_1=00000000 2=00000000 3=00000000 4=00000000 5=00000000 
parameter_6=00000001 7=0001EA0F 8=0001EEE5 9=0001EC72 10=00000000 
previous_error=00C04200, FE014100, FE014100, FE014100 

Flags=FFFF C200 443E BCache_Disable=06 KA680, 128KB BC, 14.0 ns 
Return_stack=201406A4, Subtest_pc=20056514, Timeout=00030D40 
>>> 
>>> ! Display the CPU registers. 
>>> 
>>>t Ic 
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EA 


MEAR= 


wn 


BR=01FB8000 
SCBB=20053E00 
P1LR=00000000 


ez 


TCRO=00000000 
TCR1=00000001 
RXCS=00000000 
CR=0000D000 
QBMBR=01FF8000 
CBTCR=00004000 
PCSTS=FFFFF 800 
CCTL=00000007 
ESTS=00000000 


wn 


NICSRO=1FFF000 
NICSR9=04E204E 
ISA=08-00-2B- 


CR=000000CA 


08406010_ADD=21018040 


SLR=00002021 
POBR=80000000 
SID=13001401 
MAPEN=00000000 
TIRO=00000000 
TIR1=200775AD 
RXDB=0000000D 
DSER=00000000 
BDR=3CF808AB 
IPCRO=0000 C 
PCADR=FFFFFFF8 
BCETAG=00000000 


SAVPC=20047ECC 
POLR=00100A80 
TODR=9614FD28 

BDMTR=20084000 

TNIRO=00000000 

TNIR1=0000000F 
TXCS=00000000 

QBEAR=0000000F 

DLEDR=0000000C 

SEAR1=00000000 

PCCTL=FFFFFC13 


SAVPSL=20047ECC 
P1BR=00000000 
ICCS=00000000 

BDMKR=0000007C 
TIVRO=00000078 
TIVR1=0000007C 
TXDB=00000030 
DEAR=00000000 
SSCCR=00D55570 
CSEAR2=00000000 
ICSR=00000001 
VMAR=000007E0 


CEFSTS=00019200 NEOADR=E005BFCO NEOCMD=8000FF04 


DSSI_1=03 (BUS_1) PQBBR_1=0 
PSR_1=00000000 PESR_1=0 
DSSI_2=07 (BUS_0) PQBBR_2=0 
PSR_2=00000000 PESR_2=0 


3  3=00004030 4 
2 10=00040000 11 
16-01- 


3060022 PMC 


0000000 
3060022 PMC 
0000000 
=00004050 5= 


=00000000 12= 


MESR=000FF000 


SR_1=00000000 


PFAR_1=00000000 


SR_2=00000000 


PFAR_2=00000000 
6=83E0F000 
13=00000000 15=0000FFFF 


8039FF00 
00000000 


TEST 


BCETSTS=00000000 
BCETIDX=00000000 
BCEDSTS=00000700 
BCEDIDX=00000008 
BCEDECC=00000000 
NEDATHI=00000000 
NEDATLO=00000000 
CESR=00000000 
CMCDSR=0000C108 
CIOEAR1=010FC000 
CIOEAR2=000002C0 
CNEAR=00000000 
NEICMD=00000000 
SSHMA_1=00008A20 
PPR_1=00000000 
SSHMA_2=0000CA20 
PPR_2=00000000 
7=00000000 


EMCON_0:3; 0=80000003, 1=81000003, 2=00000007, 3=00000007 #§MMCDSR=01111000 
EMCON_4:7; 4=00000007, 5=00000007, 6=00000007, 7=00000007 MOAMR=00000000 
>>> 
>>> ! List all of the diagnostic tests. 
>>> 
>>>t Ye 
Test 
# Address Name Parameters 
20053E00 SCB 
20054E14 De_executive 


30 20063AD0 
31 20064264 
32 20064D60 
33 20064EFC 
34 2005B714 
35 20067AF8 
37 2006849C 
3F 200644EC 
40 200626B8 
200564FC 
2005A3B0 
2006782C 
20063FF0 
2006185C 
200634D4 
200631E0 
20061F8C 
20062B70 
200616DC 
20061D90 
200628BC 
51 2005A870 
52 2005ABB0 
53 2005AE80 
54 2005A486 
55 2005B036 
56 2005FF1C 
58 20060798 
59 2005F064 
5C 2005F5CC 
5F 2005E350 
60 2005DD4B 
63 2005B5B8 


SS 


a a rt Sr 


ner 


i 
YAO QWPODADNE 


NS 


emory_Init_Bitmap 
emory_Setup_CSRs 
NMC_registers 
MC_powerup 
SSC_ROM 
B_Cache_diag_mode 
Cache_w_Memory 
em_FDM_Addr_short 
emory_count_pages 
Board_Reset 
Chk_for_Interrupts 
P_Cache_diag_mode 
emory_Refresh 
emory_Addr_shorts 
emory_FDM 
emory_ECC_SBEs 
emory_Byte_Errors 
emory_ECC_Logic 
emory_Address 
emory_Byte 
emory_Data 

FPA 
SSC_Prog_timers 
SSC_TOY_Clock 
Virtual_Mode 
Interval_Timer 
SHAC_LPBCK 
SHAC_RESET 
SGEC_LPBCK_ASSIST 
SHAC 

SGEC 
SSC_Console_SLU 
QDSS_any 


*** mark _Hard_SBEs ****** 


KKKKKKKKKK 
KKKKKKKKKK 
kk 

* 


bypass_test_n 
bypass_test_n 


s *** cont_on_ 


ask KKKKKKKKK 
ask KKKKKKKKK 
err KkKKKKK 


First_board Last_bd Soft_errs_allowed ******* 
* 


KKKKK 


bypass_test_n 


ask KKKKKKKKK 


start_a end incr cont_on_err time_seconds ***** 
start_add end_add * cont_on_err pat2 pat3 **** 


*** cont_on_e 
start_add end 


rr KeKKKK 


add add_incr cont_on_err ****** 


start_add end_add add_incr cont_on_err ****** 


start_add end_add add_incr cont_on_err ****** 


start_add end 


add add_incr cont_on_err ****** 


start_add end 


add add_incr cont_on_err ****** 


start_add end 


add add_incr cont_on_err ****** 


KKKKKKK 


which_timer w 


ait_time_us *** 


repeat_test_250ms_ea Tolerance *** 


KKKKKKKKK 
KKKKK 
KKKKKKKK 


dssi_bus port_number time_secs 


time_secs ** 
shac_number * 


KkKKKKK 


loopback_type no_ram_tests ****** 


start_BAUD en 


d_BAUD KkKKKKK 


input_csr selftest_r0 selftest_r1l ****** 
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20065330 
2005B21A 
2005B3DF 
200577DE 
20058E98 
20056A24 
20056RE0 
2005A0DC 
2005AB2E 
2005AAC4 
200650F8 
2005D064 
20064F7C 
2005B7DE 
2005E11C 
2005B1EC 
20060D30 
200566D0 
200568A6 
2005E23E 
20056614 


CQBIC_memory 
Qbus_MSCP 
Qbus_DELQA 
QZA_Intlpbckl 
QZA_Intlpbck2 
QZA_memory 
QZA_DMA 
QZA_EXTLPBCK 
CQBIC_registers 
CQBIC_powerup 
Flush_Ena_Caches 
INTERACTION 
Init_memory_16MB 
List_CPU_registers 
Utility 
List_diagnostics 
Create_A0_Script 
SSC_RAM Data 
SSC_RAM_Data_Addr 
SSC_registers 
SSC_powerup 


bypass_test_mask ********# 
IP csr *k*eKK 

device_num_addr **** 

controller_number ******x** 
controller_number ******x*xx 

incr test_pattern controller_number ******* 
Controller_number main_mem_buf ******** 


controller_number **** 
* 


kk 


dis_flush_virtual dis_flush_backup dis_flush_primary 


pass_count disable_device **** 
* 


* 

Expnd_err_msg get_mode init_LEDs clr_ps_cnt 
* 

KKKEKKKKKKK 

* 

* 

* 

KKKKKKKKK 


TEST 


Test 

# Address Name Parameters 

DO 20067400 V_Cache_diag_mode bypass_test_mask *******x** 

D2 20065A5C O_Bit_diag_mode bypass_test_mask ******x*x 

DA 200682C4 PB _Flush_Cache REI E 

DB 200661F0 Speed print_speed ******xxx 

DC 20064490 NO_Memory_present ******x** 

DD 200669A0 B _Cache_Data_debug start_add end_add add_incr ******* 

DE 20066558 B Cache _Tag_Debug start_add end_add add_incr ******* 

DF 20065E30 O_BIT_DEBUG start_add end_add add_incr seg_incr ****** 
Scripts 

# Description 

AQ User defined scripts 

Al Powerup tests, Functional Verify, continue on error, numeric countdown 
A3 Functional Verify, stop on error, test # announcements 

A4 Loop on A3 Functional Verify 


AS 
Ao 
Al 
A8 
A9 
>>> 


Address shorts test, run fastest way possible 

emory tests, mark only multiple bit errors 

emory tests 

emory acceptance tests, mark single and multi-bit errors, call A7 
emory tests, stop on error 
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UNJAM 

Format 
UNJAM 

Qualifiers 
None. 

Arguments 
None. 

Description 
An I/O bus reset is performed. This is implemented by writing 1 to IPR 55. 
Additionally, the SGEC and SHAC chips are explicitly software reset because 
PR$_IORESET has no effect on them. 

Examples 


>>>un jam 
>>> 
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X - Binary Load and Unload 


Format 


Qualifiers 


Arguments 


Description 


X {address} {count} <CR> {line_checksum} {data} {data_checksum} 


None. 


None. 


The X command is for use by automatic systems communicating with the console. 
It is not intended for use by operators. 


The console loads or unloads (that is, writes to memory, or reads from memory) 
the specified number of data bytes, starting at the specified address through the 
console serial line, regardless of which device is serving as the system console. 


If bit 31 of the count is clear, data is to be received by the console, and deposited 
into memory. If bit 31 of the count is set, data is to be read from memory and 
sent by the console. The remaining bits in the count are a positive number 
indicating the number of bytes to load or unload. 


The console accepts the command upon receiving the carriage return. The next 
byte the console receives is the command checksum, which is not echoed. The 
command checksum is verified by adding all command characters, including the 
checksum and separating whitespace (but not including the terminating carriage 
return or rubouts or characters deleted by rubout), into an 8-bit register initially 
set to zero. If no errors occur, the result is zero. If the command checksum is 
correct, the console responds with the input prompt and either sends data to the 
requester or prepares to receive data. If the command checksum is in error, the 
console responds with an error message. The intent is to prevent inadvertent 
operator entry into a mode where the console is accepting characters from the 
keyboard as data, with no escape mechanism possible. 


If the command is a load (bit 31 of the count is clear), the console responds 
with the input prompt, then accepts the specified number of bytes of data for 
depositing to memory, and an additional byte of received data checksum. The 
data is verified by adding all data characters and the checksum character into 
an 8-bit register initially set to zero. If the final contents of the register is non- 
zero, the data or checksum are in error, and the console responds with an error 
message. 


If the command is a binary unload (bit 31 of the count is set), the console 
responds with the input prompt, followed by the specified number of bytes of 
binary data. As each byte is sent, it is added to a checksum register initially set 
to zero. At the end of the transmission, the 2’s complement of the low byte of the 
register is sent. 
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If the data checksum is incorrect on a load, or if memory errors or line errors 
occur during the transmission of data, the entire transmission is completed 
and the console issues an error message. If an error occurs during loading, the 
contents of the memory being loaded are unpredictable. 


Echo is suppressed during the receiving of the data string and checksums. 


To avoid treating flow control characters from the terminal as valid command line 
checksums, all flow control is terminated at the reception of the carriage return 
terminating the command line. 


It is possible to control the console serial line through the use of the control 
characters (Control-C, Control-S, Control-O, etc.) during a binary unload. It is 
not possible during a binary load because all received characters are valid binary 
data. 


Data being loaded with a binary load command must be received by the console 
at a rate of at least one byte every 60 seconds. The command checksum that 
precedes the data must be received by the console within 60 seconds of the 
carriage return that terminates the command line. The data checksum must 

be received within 60 seconds of the last data byte. If any of these timing 
requirements are not met, the console aborts the transmission by issuing an error 
message and prompting for input. 


The entire command, including the checksum, can be sent to the console as a 
single burst of characters at the console serial line’s specified character rate. The 
console is able to receive at least 4 KB of data with a single X command. 
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XDELTA 


Format 


Qualifiers 


Arguments 


Description 


XDELTA 


/CONTINUE 
Enter XDELTA in "step" mode. 


None. 


The KA680 XDELTA debugger is a subset of the VMS XDELTA debug 
utility. Although a command summary appears in Table 12-14, consult the 
VMS DELTA /XDELTA Utility Manual for a complete description of supported 
commands. 


Table 12-14 XDELTA Command Summary 


Command Description 

[m Set Display Mode 

[x]L,yl/ Open Location and Display Contents in Prevailing Width Mode 
[x]Lyl! Open Location and Display Contents in Instruction Mode 
LINEFEED Close Current Location, Open Next Location 

ESCAPE Close Location, Open and Display Previous Location 
TAB Close Location, Open and Display Indirect Location 
[x]L,y]" Open Location and Display Contents in ASCII Mode 
RETURN Close Current Location 

[z][,nJL,dJ[,c]l;B | Breakpoint 

3P Proceed from Breakpoint 

[glG Go 

Ss Step Instruction 

O Step Instruction Over Subroutine 

*string’ Deposit ASCII String 

c;E Execute Command String 

1,b3X Load Base Register 


(continued on next page) 
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Table 12-14 (Cont.) XDELTA Command Summary 


Command 


Description 


expression= 


Display Value of Expression using +, -, *, %, and @ 


The following list describes XDELTA command parameters represented in the table by lowercase letters: 


m : Display mode, either B(byte), W(word), or L(longword) 


Tm AoBN< K 


: Address of location to be displayed 

: Last address of a range (beginning with address x) to be displayed 

: Breakpoint address 

: Number of the breakpoint (2..8) 

: Address of an XDELTA command string to be executed (on breakpoint) 
: Address of location to be displayed on breakpoint 

: Address at which to begin execution 
: Address to deposit in base register 

: Number of base register (0..F) 


Square brackets [] around a parameter indicate that it is optional. 


Table 12-15 XDELTA Symbols 


Symbol Description 

: Current address, the address of the current location. 

Q The last value displayed. 

Xn Base registers n, 0 to F, used to reference data structures. 

Rn General-purpose register n, 0 to F, RF+4 is the PSL. 

Pn Internal processor register n. 

G System space address prefix; that is, G2E is equivalent to 8000002E. 

H Process control region address prefix; that is, H2E is equivalent to 7FFEO02E. 
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When the console XDELTA command is executed, control is passed to the 

ROM based XDELTA utility. XDELTA diplays the current user PC address (if 
defined, else 20040000) and the instruction at that location and then awaits a 
command. In this mode of operation, XDELTA instruction stepping and program 
executions are disabled. However, it is possible to examine machine state and set 
breakpoints in a user program. 


Using ;P in this context returns control to the console. The CONTINUE 
command may then be used run the user program. If an XDELTA breakpoint 
is encountered, the address and instruction are displayed and XDELTA awaits 
further commands. At this point normal XDELTA debugging may proceed, 
including single-stepping and running the user program. 


Alternatively, XDELTA/CONTINUE can be used to trace trap into a user program 
at the address specified by the PC. Using this option enables single-stepping 
program execution, and the complete services of the firmware XDELTA utility. 


Users should keep in mind that the XDELTA facility utilizes both the trace trap 
and breakpoint vectors of the active SCB. If XDELTA is to be used to debug a 
program that establishes its own SCB, the trace trap (SCB+28) and breakpoint 
(SCB+2C) vectors should be copied from the firmware SCB to the user’s SCB. 
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Examples 


>>>ex/p/ins/n:9 1200 
P 00001200 9E MOVAB’ 4L*0000121D,R0 
P 00001207 DB MFPR S*#22,R1 
P 0000120A EF EXTZV S*#07,S*#01,R1,R1 
P 0000120F 13 BEQL 00001207 
P 00001211 9A MOVZBL (RO)+,R1 
P 00001214 13 BEQL 0000121B 
P 00001216 DA MTPR R1,S*#23 
P 00001219 11 BRB 00001207 
P 0000121B 01 NOP 
P 0000121C 00 HALT 
>>>ex pc 
G 0000000F 00001200 
>>>xdelta 


Stepping is disabled... 


00001200/MOVAB L*0000121D,R0 S 
EH? 

37 BFP 

>>>continue 


1 BRK AT 00001200 

00001200/MOVAB L*0000121D,RO SS 
00001207/MFPR S*#22,R1 S$ 
0000120A/EXTZV S*#07,S*#01,R1,R1 
XLOAD succeeded loading XTEST.EXE! 


206 HLT INST 

PC = 0000121D 
>>>dep pce 1200 
>>>xdelta/continue 


00001200/MOVAB L*0000121D,RO S 
00001207/MFPR S*#22,R1 S$ 

0000120A/EXTZV  S*#07,S*#01,R1,R1 
XLOAD succeeded loading XTEST.EXE! 


206 HLT INST 
PC = 0000121D 
>>> 


XDELTA 
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! - Comment 


Format 


Qualifiers 


None. 


Arguments 


None. 


Description 


The comment command character is used to include optional text, which you can 
use to identify a command line or add descriptions. It can appear anywhere on 
the command line. All characters following the comment character are ignored. 


Examples 


>>>! The console ignores this line. 
>>> 
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Table 12-16 Console Command Summary 
Command Qualifiers Argument Other(s) 
BOOT /R5:{boot_flags} /{boot_flags} [{boot_device}] — 
CONFIGURE — — — 
CONTINUE — — — 
DEPOSIT /B /W /L./Q —/G/I/V /P /M /U {address} {data} [{data}] 
/N:{count} /STEP: {size} (WRONG 
EXAMINE /B /W /L./Q —/G/L/V /P /M /U [{address}] _ 
/N:{count} /STEP:{size} (WRONG 
/INSTRUCTION 
FIND /MEM /RPB — — 
HALT — = = 
HELP = — = 
INITIALIZE _ = = 
MOVE /B /W /L/Q—/V /P /U {src_address} {dest_address} 
/N:{count} /STEP:{size} (WRONG 
NEXT — [{count}] — 
REPEAT — {command} — 
SEARCH /B /W /L./Q —/V /P /U {start_address} {pattern} [{mask}] 


SET BFL(A)G 
SET BOOT 

SET CONTROLP 
SET HALT 

SET HOST 

SET HOST 


SET HOST 


SET LANGUAGE 
SET RECALL 
SHOW BFL(A)G 
SHOW BOOT 


SHOW CONTROLP 


SHOW DEVICE 
SHOW DSSI 


SHOW ETHERNET 


SHOW HALT 


SHOW LANGUAGE 


SHOW MEMORY 


/N:{count} /STEP:{size} /(WRONG 
/NOT 


/DUP /DSSI /BUS:{0/1} 


/DUP /UQSSP {/DISK ! /TAPE } 
/DUP /UQSSP 


/MAINTENANCE /UQSSP /SERVICE 
/MAINTENANCE /UQSSP 


/FULL 


{bitmap} 
{device_string} 
{0/1} 
{halt_action} 
{node_number} 


{controller_ 
number} 
{csr_address} 


{controller_ 
number} 
{csr_address} 


{language_type} 
{0/1} 


[{task}] 


[{task}] 
[{task}] 


(continued on next page) 
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Table 12-16 (Cont.) Console Command Summary 


Command 


Qualifiers 


Argument 


Other(s) 


SHOW QBUS 
SHOW RECALL 
SHOW RLV12 
SHOW SCSI 


SHOW 
TRANSLATION 


SHOW UQSSP 
SHOW VERSION 
START 

TEST 

UNJAM 

Xx 

XDELTA 


/CONTINUE 


{phys_address} 


{address} 
{test_number} 


{address} 


[{parameters}] 


{count} 
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Table 12-17 Console Qualifier Summary 


Data Control 


/B 

/W 

/L 

/Q 
/N:{count} 
/STEP:{size} 


/WRONG 


Byte, legal for memory references only. 

Word, legal for memory references only. 

Longword, the default for GPR and IPR references. 
Quadword, legal for memory references only. 
Specifies number of additional operations. 


Overrides the default step incrementing size with the value specified for the current 
reference. 


On writes, uses the value of 3, which always generates double bit errors. Ignores 
ECC errors on reads of main memory. 


Address Space Control 


Se @ 


General-purpose registers 

Internal processor registers 

Virtual memory 

Physical memory, both VAX memory and I/O spaces 
Protected memory (ROMs, SSC RAM, PFN bitmap, etc.) 
Machine state (PSL) 


(continued on next page) 
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Table 12-17 (Cont.) Console Qualifier Summary 
Command-Specific 


/INSTRUCTION EXAMINE command only. Disassembles the instruction at address specified. 

/NOT SEARCH command only. Inverts the sense of the match. 

/R5:{boot_flags}, BOOT command only. Specifies a function bitmap to pass to VMB through R5. Refer 
/{boot_flags} to Figure 12-9 for a bit description of R5. Either form of the command is acceptable. 
/RPB, /MEM FIND command only. Searches for valid RPB or good block of memory. 

/DUP, /DSSI, SET HOST command only. Refers to command description for usage. 

/UQSSP, 

/DISK, /TAPE, 

/MAINTENANCE, 

/SERVICE 

/CONTINUE XDELTA command only. Enters XDELTA step mode at current PC. 


Nomenclature for Table 12-16 and Table 12-17 : 


UPPERCASE denotes the command or qualifier keyword. 

{} denotes a mandatory item that must be syntactically correct. 
[] denotes an optional item. 

! denotes an "or" condition. 


And 


boot_flags, count, size, address, and parameters denote hex longword values. 
boot_device denotes a legal boot device name. 

csr_address denotes a Q22-bus I/O page CSR address. 

controller_number denotes a controller number from 0 to 255. 

halt_action denotes the value of the user-defined halt action from 0 to 4. 
language_type denotes the language value, from 1 to 15. 

command denotes a console command other than REPEAT. 

data, pattern, and mask denote hex values of the current size. 

test_number denotes hex byte test number. 
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12.3 Diagnostics 


The ROM-based diagnostics constitute the bulk of the firmware on the KA680. 
These diagnostics run automatically on powerup and can be executed interactively 
as a whole, or as individual tests using the TEST command. (See Section 
Section 12.2.9, Console Commands.) This section summarizes the operation of the 
ROM-based diagnostics. 


The purpose of the ROM-based diagnostics is multifaceted: 


1. During powerup, they determine if enough of the KA680 is working to allow 
the console to run. 


2. During the manufacturing process, they verify that the board was correctly 
built. 


3. In the field, they verify that the board is operational and able to report all 
detected errors. 


4. They allow sophisticated users and field service technicians to run individual 
diagnostics interactively, with the intent of isolating errors to the FRU (field 
replaceable unit). 


To accommodate these requirements, the diagnostics are designed as a collection 
of individual parameterized tests. A data structure, called a script, and a 
program, called the diagnostic executive, orchestrate the running of these tests in 
the right order with the right parameters. 


A script is a data structure that points to various tests. There are several 
scripts, one for the field and several for manufacturing, depending where on the 
manufacturing line the board is. Sophisticated users may also create their own 
scripts interactively. Additionally, the script contains other information: 


¢ What parameters need to be passed to the test. 

¢ What is to be displayed, if anything, on the console. 
¢ What is to be displayed, if anything, on the LED. 

¢ What to do on errors (halt, loop, or continue). 


¢ Where the tests may be run from. For example, there are certain tests that 
can only be run from the FEPROM. Other tests are PIC (position independent 
code), and may be run from FEPROM or main memory in the interests of 
execution speed. 


The diagnostic executive "interprets" scripts to determine what tests are to 
be run. There are several built-in scripts on the KA680 that are used for 
manufacturing, power-up, and Digital Services personnel. The diagnostic 
executive automatically invokes the correct script based on the current 
environment of the KA680. Any script can be explicitly run with the TEST 
command from the console terminal. 


The diagnostic executive is also responsible for controlling the tests so that when 
errors occur, they can be caught and reported to the user. The executive also 
ensures that when the tests are run, the machine is left in a consistent and 
well-defined state. 
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12.3.1 Error Reporting 
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Before a console is established, the only error reporting is via the KA680 
diagnostic LEDs (and any LEDs on other boards). Once a console has been 
established, all errors detected by the diagnostics are also reported by the 
console. When possible, the diagnostics issue an error summary on the console. 


For example, Figure 12—14 shows a typical error display. 


Figure 12-14 Diagnostic Register Dump 


?9A 2 02 FF 0000 0000 01 ; SUB 


P1=00000002 
P6=00000000 
r0=00000054 
r5=30002800 


P2=00000000 
P7=00000002 
r1=00000040 
r6=0000C4E0 


P3=00004000 
P8=00000002 
r2=00000000 
r7=20008000 


TEST_9A_02, DE_INTERACTION.LIS (1) 
P4=00008000 P5=0000C000 (2) 
P9=84004000 P10=00001FFF (3) 
r3=0000C524 r4=00000014 (4) 
r8=00004000 EPC=20057BBD (5) 


Normal operation not possible. 


242 2 CO FF 00D4 0000 00 


P1=00000003 
P6=21020020 
r0=000000C0 
r5=20059FCB 


P2=00FC00C0 
P7=00000000 
r1=0000002E 
r6=200680C7 


; SUBT 


P3=000000D4 
P8=00000000 
r2=00000042 
r7=00000000 


EST_42_ C0, DE_Chk_for_Interrupts.LIS 


P4=00000000 P5=00000000 
P9=FFFFFFFF P10=00000002 
r3=20140778 r4=20059FA8 
r8=00000008 EPC=2005A047 


SCBB=20053A00 TODR=0446A76E 
SCR=0000D000 DSER=00000000 QBEAR=0000000A DEAR=00000000 
QBMBR=01FF8000 BDR=38FB08AB SSCCR=00D55570 IPCRO=0020 
NCAERR=00000000 NCAMODE=0000C108 CP1SEA=00000000 CP2SEA=00000000 
CP1IOEA=010FC000 CP2IOFA=1015C400 NDALEA=00000000 MAPEN=00000000 
PCSTS=FFFFF800 PCADR=FFFFFFF8  PCCTL=FFFFFE13 
ICSR=00000001 VMAR=000007E0 VTAG=20041200 VDATA=FFC13101 
CCTL=00000007 BCETSTS=00000000 BCETIDX=00000000 BCETAG=00000000 
BCEDSTS=00000700 BCEDIDX=00000008 CEFSTS=00019200 BCEDECC=00000000 
CEFADR=F015C400 NESTS=00000000 NEOADR=EO05C7E8 §NEOCMD=8000FF04 
NEICMD=00000000 NEDATHI=00000000 NEDATLO=00000000 OBITMODE=00000340 
NMCMODE=09115C20 NMCEA=08406010 ADD=21020040 NMCERR=000FF000 
MEMCON_0:7; 0=80000003, 1=81000003 
2=00000007, 3=00000007, 4=00000007, 


ECR=000000CA LIS_ADD=009F 


5=00000007, 6=00000007, 7=00000007 
In Figure 12-14, the numbers in parentheses on the right side refer to lines of 
the display and are not a part of the diagnostic dump. The information on these 


lines is summarized below. 
1. Test summary containing six hexadecimal fields. 
a. ?9A, test identifies the diagnostic test. 


b. 2, severity is the level of a test failure, as dictated by the script. A 
severity level 2 error causes the display of this 5-line error printout, and 
halts an autoboot to console I/O mode. A severity level 1 error displays 
the first line of the error printout, but does not interrupt an autoboot. 
Most tests have a severity level of 2. 


c. 02, subtestlog is a number, that in conjunction with listing files, isolates 
to within a few instructions where the diagnostic detected the error. 


d. FF, de_error is a code with which the diagnostic executive signals the 
diagnostic’s state and any illegal behavior. This field indicates a condition 
that the diagnostic expects on detecting a failure. The possible codes are: 


FF - Normal error exit from diagnostic 
FE - Unanticipated interrupt 
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FD - Interrupt in cleanup routine 

FC - Interrupt in interrupt handler 

FB - Script requirements not met 

FA - No such diagnostic 

EF - Unanticipated exception in executive 


e. 0000, vector is the SCB vector (if nonzero) through which an unexpected 
exception or interrupt trapped when the de_error field indicates an 
unexpected exception or interrupt (FE or EF). 


f. 0000, count is the number of previous errors that have occurred. 


g. 01, loop_subtest is an additional subtestlog generated out of the context 
of the current test as specified by the current test number and subtestlog. 
Usually these logs occur in common subroutines called from a diagnostic 
test. 


h. SUBTEST_9A_02, subtest_symbol is a unique symbol that identifies the 
most recent subtestlog entry in the listing file. 


i. DE_INTERACTION.LIS, listing_file is the name of the listing file that 
contains the failed diagnostic. 


2. P1...P5 are the first five parameters containing diagnostic state. 

3. P6...P10 are the last five parameters containing diagnostic state. 

4. RO...R4 are the first five GPRs at the moment the error was detected. 
5. R5...R8 are additional GPRs and EPC is PC at the time of the error. 


The use of parameters and registers varies with each test. The appropriate listing 
file should be consulted for interpretation of these parameters and registers in 
determining diagnostic state. 


12.3.2 Diagnostic Interdependencies 


When running tests interactively on an individual basis, users should be aware 
that certain tests may be dependent on some state set up from a previous test. In 
general, tests should not be run out of order. 


12.3.3 Areas Not Covered 


The goal has been to achieve the highest possible coverage on the KA680 and 
the memory boards. However, the testing of the KA680 while running with 
memory management turned on is minimal. Also, due to the way the firmware is 
implemented (a polled environment running at IPL 31), the testing of interrupts 
is not extensive. 


These diagnostics are not intended to be used as system level tests. There are 
no tests to completely verify that access to the Q22-bus will work. Thus, a disk, 
a controller, the backplane, or portions of the CQBIC may be faulty, and the 
diagnostics may not detect the fault. Such a fault may result later as an inability 
to boot. 


KA680 Firmware 12-85 


KA680 Firmware 
12.4 Environment 


12.4 Environment 


The following is a description of the intended environment in which KA680 
firmware will be used. This environment includes not only the surrounding 
hardware, but also the field of use. 


12.4.1 Users 


Engineering, Manufacturing, Digital Services, and customers will use this 
program to test, configure, and boot their KA680 modules. This firmware will be 
used to provide both an easy means to bootstrap a KA680 based system and to 
detect and isolate system malfunctions. 


Of these users, all but customers are assumed to be computer "sophisticates." 
While this will often be true of customers as well, no such assumption is made. 
Target customers include both sophisticated users who can use and understand 
all the features provided by the firmware, as well as unsophisticated users who 
know little about computers. 


Users are not assumed to speak English. The console program can be configured 
to output critical console messages in either English, French, German, Spanish, 
Italian, Norwegian, Dutch, Swedish, Finnish, Danish, or Portuguese. When the 
module powers up without a specified language, KA680 prompts the user for the 
language to be used to display critical system messages. The selected language 
is recorded in battery backed-up RAM in order to retain the preferred language 
when the system is powered down. 


12.4.2 Hardware 
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The firmware described in this document resides on the KA680 module. The 
KA680 is an NVAX based Q22-bus CPU module with off-board expansion 
memory. Additionally, the KA680 is specifically designed to consolidate other 
"system" components on a single module. In particular, the KA680 has an on- 
board Ethernet adapter for network communications and integral DSSI ports for 
connection of mass storage devices. The KA680 provides a local serial I/O port for 
support of a standard VAX console. 


The KA680 continues to support communications with other Q22—bus modules 
through its Q22-bus interface consisting of a scatter/gather map, a direct map of 
the Q22-bus I/O page and memory through VAX I/O space, and interprocessor 
communication registers. Because the KA680 processor is intended to be the 
Q22-bus arbiter, the use of the KA680 as an auxiliary processor is unsupported. 


The KA680 provides a maximum of 512KB of FEPROM for the firmware. The 
firmware resides on the KA680 module in four 128KB FEPROM, located at 

the VAX restart location in I/O space at physical address E0040000. Unlike its 
predecessors, the KA680 firmware image appears only once in I/O space and the 
entire image runs halt-protected. 


Note 


All public call-in routines in the ROMs also run halt-protected and exit 
through SSC RAM so that halt protection is turned off when returning 
to the caller. Unsupported call-ins to ROM utilities may result in halt 

protection forced outside the FEPROM extent. 
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For the firmware to operate, the processor must be functioning to the point of 
executing instructions from the firmware FEPROM. This assumes that the NVAX 
core set of chips is operating correctly. 


The firmware uses the KA680 module LEDs and a console terminal to display 
diagnostic progress, display error conditions, and indicate the current mode of 
operation. Additionally, the console terminal is used as the primary operator 
interface when in console I/O mode. 


Note 


A console terminal is not required for operation because the module can 
be configured to bootstrap automatically. However, in most scenarios, a 
console terminal is a recommended part of a standard configuration. 


12.4.3 Software 


The KA680 firmware runs standalone, and does not require other software 
products for normal operation in "console I/O mode." However, in most situations, 
an operating system (or other image) is loaded in KA680 local memory and 
control is transferred to it. When the operating system is running, the processor 
is in "program I/O mode." (The terms console I/O mode and program I/O mode 
refer to the context and usage of the console terminal.) 


The KA680 will support the Digital standard operating systems: VMS and 
VAXELN. Additionally, the firmware will support bootstrap of MDM and other 
diagnostics images. Furthermore, the console will support communication with 
an APT host in manufacturing environments via the console serial line. 


12.4.4 Services 


The KA680 firmware is an integral part of the module and does not require 
installation or support services. However, if an ECO is required, it may be 
applied in the field by the customer. 
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12.5 Internationalization 


Most firmware message text is either multilingual or language-independent. The 
messages displayed on powerup and system failures are multilingual. Depending 
on user preference, these messages are output in either English, French, German, 
Italian, Portuguese, Spanish, Dutch, Danish, Finnish, Norwegian, or Swedish. 
All other messages are language-independent; they are constructed of short, 
language-insensitive abbreviations rather than readable sentences. 


Numeric status displays on the processor LEDs facilitate the diagnosis of failing 
processors in a language-independent manner. 


The operation of the console is independent of the user’s line voltage or frequency. 


The console supports the Digital Multinational Character Set (MCS). This 
support extends to: displaying foreign language messages with MCS, accepting 
and echoing MCS characters, and accepting a device attributes report (console 
queries the terminal to determine if it is a CRT or not) using the C1 control 
characters of MCS. However, all console commands must be entered using the 
ANSI subset. 


If the terminal does not support MCS, the console uses English message texts. 


The console program uses four characters that are National Replacement 
Characters (NRCs): the caret "’", the backslash "\", and the left and right square 
brackets "[", "]". The caret is used by the console to denote control characters. 
The backslash is used to delimit text deletions when editing console input. The 
square brackets are used to denote directory specifications when the user directs 
the bootstrap to solicit a secondary bootstrap file name. No provision is made for 
terminals that replace any of these characters on output; however, use of angle 
brackets "<" and ">" for directory specifications on input is acceptable. 
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NVRAM Partitioning 


This appendix describes how the KA680 firmware partitions the SSC 1 KB 
battery backed-up (BBU) RAM. 


A.1 SSC RAM Layout 


The KA680 firmware uses the 1 KB of NVRAM on the SSC for storage of 
firmware-specific data structures and other information that must be preserved 
across power cycles. This NVRAM resides in the SSC chip starting at address 
20140400. The NVRAM should not be used by the operating systems except 
as documented below. This NVRAM is not reflected in the bitmap built by the 
firmware. 


Figure A-1 KA680 SSC NVRAM Layout 
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Firmware Stack 


Diagnostic State 


201407FC Rsvd for Customer Use 


A.1.1 Public Data Structures 


The following is a list of the public data structures in NVRAM used by the 
console. 


Fields that are desginated as reserved and/or internal use should not be written 
because there is no protection against such corruption. 


A.1.2 Console Program MailBoX (CPMBX) 


The Console Program MailBoX (CPMBX) is a software data structure located at 
the beginning of NVRAM (20140400). The CPMBxX is used to pass information 

between the KA680 firmware and diagnostics, VMB, or an operating system. It 
consists of three bytes (referred to here as NVRO, NVR1, and NVR2). 
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Figure A-2 NVRO (20140400) : Console Program MailBoX (CPMBX) 
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NVRO LANGUAGE RIP | BI HLT_ACT 


Table A-1 CPMBX NVRO 


Field Name 


Description 


7:4 LANGUAGE 


3 RIP 
2 BIP 
1:0 HLT_ACT 


This field specifies the current selected language for displaying 
halt and error messages on terminals that support MCS. 


If set, a restart attempt is in progress. This flag must be cleared 
by the operating system if the restart succeeds. 


If set, a bootstrap attempt is in progress. This flag must be 
cleared by the operating system if the bootstrap succeeds. 


Processor halt action - This field, in conjunction with the 
conditions specified in Table 12-1, is used to control the 
automatic restart/bootstrap procedure. HLT_ACT is normally 
written by the operating system. 


: Restart; if that fails, reboot; if that fails, halt. 
: Restart; if that fails, halt. 

: Reboot; if that fails, halt. 

: Halt. 


WNrRO 
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Figure A-3_ NVR1 (20140401) 
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Table A-2_ CPMBX NVR1 


Field Name Description 

2 MCS If set, indicates that the attached terminal supports 
Multinational Character Set. If clear, MCS is not supported. 

1 CRT If set, indicates that the attached terminal is a CRT. If clear, 


indicates that the terminal is hard copy. 


Figure A-4 NVR2 (20140402) 
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NVR2 KEYBOARD 


Table A-3 CPMBX NVRO 
Field Name Description 


7:0 KEYBOARD This field indicates the national keyboard variant in use. 


A.1.3 Firmware Stack 


This area contains the stack that is used by all the firmware (except VMB, which 
has its own built-in stack). 


A.1.4 Diagnostic State 


This area is used by the firmware-resident diagnostics. It is not documented here. 


A.1.5 USER Area 


The KA680 console reserves the last longword (address 201407FC) of the NVRAM 
for customer use. This location is not tested by the console firmware. Its value is 
undefined. 
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Data Structures 


This appendix contains definitions of key global data structures that are used by 
the KA680 firmware. 


B.1 Halt Dispatch State Machine 


The KA680 halt dispatcher determines what actions the firmware will take on 
halt entry, based on the machine state. The dispatcher is implemented as a 
state machine, which uses a single bitmap control word and the transition table 
(Table B—1) to process all halts. The transition table is sequentially searched for 
matches with the current state and control word. If there is a match, a transition 
occurs to the next state. 


The control word is comprised of the following information. 


¢ Halt Type, used for resolving external halts. Valid only if Halt Code is 00. 


000 : 
001 : 
010: 
O11: 
100: 
101: 


Power-up state 

Halt in progress 

Negation of Q22—bus DCOK 

Console BREAK condition detected 
Q22-bus BHALT 

SGEC BOOT_L asserted (trigger boot) 


¢ Halt Code, compressed form of SAVPSL<13:8>(RESTART_CODE). 


00: 
O01: 
10: 


11: 


RESTART_CODE = 2, external halt 
RESTART_CODE = 8, power-up/reset 
RESTART_CODE = 6, halt instruction 
RESTART_CODE = any other error halts 


¢ Mailbox Action, passed by an operating system in CPMBX<1:0>(HALT_ 
ACTION). 


: Restart, boot, halt 
: Restart, halt 

: Boot, halt 

: Halt 


¢ User Action, specified with the SET HALT console command. 


000 : 
001: 
010: 
O11: 
: Restart, boot, halt 


100 


Default 
Restart, halt 
Boot, halt 
Halt 


¢ HEN, BREAK (halt) enable switch, BDR<7>. 
e ERR, error status. 


e TIP, trace in progress. 
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e DIP, diagnostics in progress. 
¢ BIP, bootstrap in progress CPMBX<2>. 
e RIP, restart in progress CPMBX<3>. 


Table B—1 Firmware State Transition Table 


Mailbox 
Current Next Halt Halt User HEN-ERR-TIP- 
State State Type Code Action Action DIP-BIP-RIP 
Perform conditional initialization. 
ENTRY —>RESET INIT XXX 01 XX XXX X-X-X-X-x-x 
ENTRY —>BREAK INIT 011 00 XX XXX X-X-X-X-xX-x 
ENTRY —>TRACE INIT xxx 10 XX XXX x-QO-1-x-x-x 
ENTRY —>OTHER INIT xxx XX XX XXX X-X-X-X-x-x 
Perform common initialization. 
RESET INIT -—>INIT XXX XX XX XXX X-X-X-X-x-x 
BREAK —>INIT XXX XX XX XXX X-X-X-X-x-x 
INIT 
TRACE INIT -—>INIT XXX XX XX XXX X-X-X-X-X-x 
OTHER —>INIT XXX XX XX XXX X-X-X-X-x-x 
INIT 
Check for external halts. ? 
INIT —>BOOTSTRAP 010 00 XX XXX O-x-x-x-x-x 
INIT —>BOOTSTRAP 101 00 XX XXX X-X-X-X-x-x 
INIT —>HALT XXX 00 XX XXX X-X-X-X-xX-x 
Check for pending (NEXT) trace. + 
INIT —>TRACE Xxx 10 XX XXX x-x-1l-x-x-x 
TRACE —>EXIT XXX 10 XX XXX x-QO-1-x-x-x 
TRACE —>HALT Xxx XX XX XXX X-X-X-X-X-x 
Check for bootstrap conditions. ° 
INIT —>BOOTSTRAP = xxx 01 XX XXX 0-0-0-0-0-0 


1 Perform a unique initialization routine on entry. In particular, powerups, BREAKs, and TRACEs 
require special initialization. Any other halt entry performs a default initialization. 


2 After performing conditional initialization, complete common initialization. 
3 Halt on all external halts, except: 


If DCOK (unlikely) and halts are disabled, bootstrap. 
If SGEC remote trigger, bootstrap. 


a Unconditionally enter the TRACE state if the TIP flag is set and the halt was due to a HALT 
instruction. From the TRACE state the firmware exits if TIP is set and ERR is clear; otherwise, it 
halts. 


2 Bootstrap, 
If powerup and halts are disabled. 
If powerup and halts are enabled and user action is 2 or 4. 
If not powerup and mailbox is 2. 


If not powerup, mailbox is 0, and user action is 2. 
If not powerup, restart failed, mailbox is 0, and user action is 0 or 4. 


(continued on next page) 
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Table B—1 (Cont.) Firmware State Transition Table 


Mailbox 

Current Next Halt Halt User HEN-ERR-TIP- 
State State Type Code Action Action DIP-BIP-RIP 
INIT —>BOOTSTRAP = xxx 01 XX 010 1-0-0-0-0-0 
INIT —>BOOTSTRAP = xxx 01 XX 100 1-0-0-0-0-0 
INIT —>BOOTSTRAP = xxx 1x 10 XXX x-0-0-0-0-0 
INIT —>BOOTSTRAP xxx 1x 00 010 x-0-0-0-0-0 
INIT —>BOOTSTRAP = xxx 1x 00 100 x-0-0-0-0-1 
INIT —>BOOTSTRAP = xxx 1x 00 100 x-1-0-0-0-x 
INIT —>BOOTSTRAP xxx 1x 00 000 0-0-0-0-0-1 
RESTART —>BOOTSTRAP xxx 1x 00 000 0-1-0-0-0-x 

Check for restart conditions. ° 
INIT —>RESTART XXX 1x 01 XXX x-0-0-0-0-0 
INIT —>RESTART XXX 1x 00 001 x-0-0-0-0-0 
INIT —>RESTART XXX 1x 00 100 x-0-0-0-0-0 
INIT —>RESTART XXX 1x 00 000 0-0-0-0-0-0 

Perform common exit processing, if 

no errors. 
BOOTSTRAP ->EXIT Xxx XX XX XXX x-QO-x-x-x-x 
RESTART —>EXIT Xxx XX XX XXX x-QO-x-x-x-x 
HALT —>EXIT XXX XX XX XXX x-O-x-x-x-x 

Exception transitions, just halt. ° 
INIT —>HALT XXX XX XX XXX X-X-X-X-x-x 
BOOT —>HALT XXX XX XX XXX X-X-X-X-X-x 
REST —>HALT Xxx XX XX XXX X-X-X-X-X-x 
HALT —>HALT XXX XX XX XXX X-X-X-X-X-x 
TRACE —>HALT XxX XX XX XXX X-X-X-X-X-x 
EXIT —>HALT Xxx XX XX XXX X-X-X-X-xX- 


5 Restart the operating system if not powerup and: 


If mailbox is 1. 
If mailbox is 0 and user action is 1 or 4. 
If mailbox is 0, user action is 0, and halts are disabled. 


7 Bxit after halts, bootstrap, or restart. The exit state transitions to program I/O mode. 


8 Guard block that catches all exception conditions. In all cases, just halt. 
"x" is used in this table to indicate a "don’t care" field. 


A transition to a "next state" occurs if a match is found between the control 
word and a "current state" entry in the table. The firmware does a linear search 
through the table for a match. Therefore, the order of the entries in the transition 
table is important. The control longword is reassembled before each transition 
from the current machine state. The state machine transitions are shown in 
Table B-1. 
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B.2 RPB 


VMB typically utilizes the low portion of memory unless there are bad pages in 
the first 128 KB. The first page in its block is used for the RPB (restart parameter 
block) through which it communicates to the operating system. Usually, this is 
page 0. 


VMB will initialize the restart parameter block (RPB) as follows: 


Table B—2 Restart Parameter Block Fields 


(R11)+ Field Name 


Description 


00: 
04: 


08: 


OC: 


10: 
10: 


18: 


1C: 


20: 


24: 
28: 
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RPB$L_BASE 


RPB$L_ 
RESTART 


RPB$L_ 
CHKSUM 


RPB$L_ 
RSTRTFLG 


RPB$L_HALTPC 


RPB$L_ 
HALTPSL 


RPB$L_ 
HALTCODE 


RPB$L_BOOTRO 


RPB$L_BOOTR1 


RPB$L_BOOTR2 
RPB$L_BOOTR3 


Physical address of base of RPB. 
Cleared. 


-1 
Cleared. 


R10 on entry to VMB (HALT PC). 
PR$_SAVPSL on entry to VMB (HALT PSL). 


AP on entry to VMB (HALT CODE). 
RO on entry to VMB. 


Note 


The field RPB$W_ROUBVEC, 
which overlaps the high order 
word of RPB$L_BOOTRQO, is set 
by the boot device drivers to the 
SCB offset (in the second page of 
the SCB) of the interrupt vector 
for the boot device. 


VMB version number. The high-order word of the version is 
the major ID and the low-order word is the minor ID. 


R2 on entry to VMB. 
R3 on entry to VMB. 
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Table B—2 (Cont.) Restart Parameter Block Fields 


(R11)+ Field Name 


Description 


2C: 


30: 
34: 


38: 
3C: 
40: 
44: 


AC: 


50: 
54: 
58: 
5C: 


60: 
64: 
66: 


RPB$L_BOOTR4 


RPB$L_BOOTR5 
RPB$L_IOVEC 


RPB$L_IOVECSZ 
RPB$L_FILLBN 
RPB$L_FILSIZ 
RPB$Q_PFNMAP 


RPB$L_PFNCNT 


RPB$L_SVASPT 
RPB$L_CSRPHY 
RPB$L_CSRVIR 
RPB$L_ADPPHY 


RPB$L_ADPVIR 
RPB$W_UNIT 
RPB$B_DEVTYP 


R4 on entry to VMB. 


Note 


The 48-bit booting node address 
is stored in RPB$L_BOOTR3 
and RPB$L_BOOTR4 for 
compatibility with VAXELN 
V1.1. (This field is initialized 
this way only when performing a 
network boot.) 


R5 on entry to VMB. 


Physical address of boot driver’s I/O vector of transfer 
addresses. 


Size of BOOT QIO routine. 
LBN of secondary bootstrap image. 
Size of secondary bootstrap image in blocks. 


The PFN bitmap is a array of bits where each bit has the 
value "1" if the corresponding page of memory is valid, or 
the value "0" if the corresponding page of memory contains 

a memory error. Through use of the PFNMAP, the operating 
system can avoid memory errors by avoiding known bad pages 
altogether. The memory bitmap is always page-aligned, and 
describes all the pages of memory from physical page #0 to 
the high-end of memory, but excluding the PFN bitmap itself 
and the Q—bus map registers. If the high byte of the bitmap 
spans some pages available to the operating system and some 
pages of the PFN bitmap itself, the pages corresponding to 
the bitmap itself will be marked as bad pages. The first 
longword of the PFNMAP descriptor contains the number 

of bytes in the PFNMAP; the second longword contains the 
physical address of the bitmap. 


Count of "good" pages of physical memory, but not including 
the pages allocated to the Q22-bus scatter/gather map, the 
console scratch area, and the PFN bitmap at the top of 
memory. 


0. 
Physical address of CSR for boot device. 
0. 


Physical address of ADP (really the address of QMRs - *x800 
to look like a UBA adapter). 


0. 
Unit number of boot device. 
Device type code of boot device. 


(continued on next page) 
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Table B—2 (Cont.) Restart Parameter Block Fields 


(R11)+ Field Name 


Description 


67: RPB$B_SLAVE 
68: RPB$T_FILE 


90: RPB$B_ 
CONFREG 

AO: RPB$B_ 
HDRPGCNT 

Al: RPBS$W_ 
BOOTNDT 


BO: RPB$L_SCBB 


BC: RPB$L_ 
MEMDSC 

Co: RPB$L_ 
MEMDSC+4 


104: RPB$L_BADPGS 
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Slave number of boot device. 


Name of secondary bootstrap image (defaults to 
[SYSO.SYSEXE]SYSBOOT.EXE). This field (up to 40 bytes) is 
overwritten with the input string on a "solicit" boot. 


Note 


1: For VAX VMS, the RPB$T_ 
FILE must contain the root 
directory string "SYSn." on a 
non-network bootstrap. This 
string is parsed by SYSBOOT 
(that is, SYSBOOT does not use 
the high nibble of BOOTRS). 

2: The RPB$T_FILE is 
overwritten to contain the boot 
node name for compatibility with 
VAXELN V1.1. (This field is 
initialized this way only when 
performing a network boot.) 


Array (16 bytes) of adapter types (NDT$_UBO0 - UNIBUS ). 
Count of header pages. 


Boot adapter nexus device type. Used by SYSBOOT and 
INIADP (OF SYSLOA) to configure the adapter of the boot 
device (changed from a byte to a word field in Version 12 of 
VMB). 


Physical address of SCB. 


Count of pages in physical memory including both good and 
bad pages. The eight high bits of this longword contain the 
TR number, which is always zero for KA680. 


PFN of the first page of memory. This field is always zero for 
KA680, even if page #0 is a bad page. 


Note 


No other memory descriptors are 
used. 


Count of "bad" pages of physical memory. 
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Table B—2 (Cont.) Restart Parameter Block Fields 


(R11)+ Field Name 


Description 


108: RPB$B_ 
CTRLLTR 


nn: — 


Boot device controller number biased by 1. In VAX VMS, 
this field is used by INIT (in SYS) to construct the boot 
device’s controller letter. A zero implies this field has not 
been initialized; else if initialized, A=1, B=2, etc. (This field 
was added in Version 13 of VMB.) 


The rest of the RPB is zeroed. 
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B.3 VMB Argument List 


The VMB code will also initialize an argument list as follows (the address of the 
argument list is passed in the AP): 


Table B—3_ VMB Argument List 


(AP)+ Field Name 


Description 


04: 


OC: 


10: 
14: 


1C: 


24: 


2C: 
80: 


84: 


3C: 


44: 


AC: 


54: 
58: 


VMB$L_ 
FILECACHE 


VMB$L_LO_PFN 


VMB$L_HI_PFN 


VMB$Q_ 
PFNMAP 


VMB$Q_ UCODE 


VMB$B_ 
SYSTEMID 


VMB$L_FLAGS 
VMB$L_CI_ 
HIPFN 


VMB$Q_ 
NODENAME 


VMB$Q_ 
HOSTADDR 


VMB$Q_ 
HOSTNAME 


VMB$Q_ TOD 


VMB$L_XPARAM 


Quadword file name. 


PFN of first page of physical memory (always zero, regardless 
of where 128 KB of "good" memory starts). 


PFN of last page of physical memory. 


Descriptor of PFN bitmap. First longword contains count of 
bytes in bitmap. Second longword contains physical address 
of bitmap. (Same rules as for RPB$Q_PFNMAP listed above.) 


Quadword. 


48-bit (actually, a quadword is allocated) booting node address 
initialized when performing a network boot. This field is 
copied from the target system address parameter of the 
parameters message. (The DECnet HIORD value is added if 
the field were two bytes.) 


Set as needed. 
Cluster interface high PFN. 


Boot node name that is initialized when performing a network 
boot. This field is copied from the target system name 
parameter of the parameters message. 


Host node address (this value is initialized only when booting 
over the network). This field is copied from the host system 
address parameter of the parameters message. 


Host node name (this value is initialized only when 
performing a network boot). This field is copied from the 
host system name parameter of the parameters message. 


Time of day (this value is initialized only when performing a 
network boot). The time of day is copied from the first eight 
bytes of the host system time parameter of the parameters 
message. (The time differential values are NOT copied.) 


Pointer to data retrieved from request of the parameter file. 


The rest of the argument list is zeroed. 
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Error Messages 


The error messages issued by the KA680 firmware fall into three categories: halt 
code messages, VMB error messages, and console messages. 


C.1 Machine Check Register Dump 


Some error conditions, such as machine check, generate an error summary 
register dump preceding the error message. For example, examining a 
nonexistent memory location results in the following display: 


>>>ex /p/1l 7f£f£ff£0 


MESR=801FF000 
CESR=00000000 
CIOEAR1=010FC000 
PCSTS=FFFFF800 
NESTS=00000000 
NEDATHI=00000000 
BCETSTS=00000000 
BCEDIDX=00000008 
QBEAR=0000000F 


MEAR=11FFFFF9 
CMCDSR=0000C108 
CIOEAR2=000002C0 
PCADR=FFFFFFF8 
NEOADR=E014066C 
NEDATLO=00000000 
BCETIDX=00000000 
BCEDECC=00000000 
DEAR=00000000 


! Examine non-existent memory. 


MMCDSR=01111000 
CSEAR1=00000000 
CNEAR=00000000 
TBSTS=C00000E0 
NEOCMD=8000F005 
CEFSTS=0000022A 
BCETAG=00000000 
CBTCR=00004000 
IPCRO=0000 


MOAMR=00000000 
CSEAR2=00000000 
ICSR=00000001 
TBADR=00000000 
NEICMD=00000000 
CEFADR=07FFFFF0 
BCEDSTS=00000700 
DSER=00000000 
ECR=000000CA 


?7D MACHINE CHECK 80060000 00000000 20047ECC 20047EBD 20047EB9 B0110080 


>>> 


C.2 Halt Code Messages 


Except on powerup, which is not treated as an error condition, the following halt 
messages are issued by the firmware whenever the processor halts. 


For example, if the processor encounters a HALT instruction while in kernel 
mode, the processor halts and the firmware displays the following before entering 


console I/O mode: 


206 HLT INST 
PC = 800050D3 


The number preceding the halt message is the "halt code." This number is 
obtained from SAVPSL<13:8>(RESTART_CODE), IPR 48, which is saved on any 
processor restart operation. 
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Table C-1 HALT Messages 


Code Message Description 

202 EXT HLT External halt caused by either console BREAK condition, Q22—bus 
BHALT_L, or DBR<AUX_HLT> bit, was set while enabled. 

203 —- Power-up, no halt message is displayed. However, the presence of 
the firmware banner and diagnostic countdown indicates the reason 
for this halt. 

204 ISP ERR In attempting to push state onto the interrupt stack during an 
interrupt or exception, the processor discovered that the interrupt 
stack was mapped NO ACCESS or NOT VALID. 

205 DBL ERR The processor attempted to report a machine check to the operating 
system, and a second machine check occurred. 

206 HLT INST The processor executed a HALT instruction in kernel mode. 

207 SCB ERR3 The SCB vector had bits <1:0> equal to 3. 

208 SCB ERR2 The SCB vector had bits <1:0> equal to 2. 

20A CHM FR ISTK A change mode instruction was executed when PSL<IS> was set. 

?20B CHM TO ISTK The SCB vector for a change mode had bit <0> set. 

20C SCB RD ERR A hard memory error occurred while the processor was trying to read 
an exception or interrupt vector. 

210 MCHK AV An access violation or an invalid translation occurred during machine 
check exception processing. 

?11 KSP AV An access violation or invalid translation occurred during processing 
of a kernel stack not valid exception. 

212 DBL ERR2 Double machine check error. A machine check occurred while trying 
to service a machine check. 

213 DBL ERR3 Double machine check error. A machine check occurred while trying 
to service a kernel stack not valid exception. 

219 PSL EXC5? PSL<26:24> = 5 on interrupt or exception. 

?1A PSL EXC6? PSL<26:24> = 6 on interrupt or exception. 

?1B PSL EXC7! PSL<26:24> = 7 on interrupt or exception. 

21D PSL REI5' PSL<26:24> = 5 on an REI instruction. 

21E PSL REI6’ PSL<26:24> = 6 on an REI instruction. 

?1F PSL REI7! PSL<26:24> = 7 on an REI instruction. 

?3F MICROVERIFY Microcode power-up self-test failed. 

FAILURE 


¥or the last six cases, the VAX architecture does not allow execution on the interrupt stack while in a mode other than 
kernel. In the first three cases, an interrupt is attempting to run on the interrupt stack while not in kernel mode. In the 
last three cases, an REI instruction is attempting to return to a mode other than kernel and still run on the interrupt 


stack. 
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C.3 VMB Error Messages 
The following errors are issued by VMB. 


Table C-2 VMB Error Messages 


Code Message Description 

240 NOSUCHDEV No bootable devices found. 

241 DEVASSIGN Device is not present. 

242 NOSUCHFILE Program image not found. 

243 FILESTRUCT Invalid boot device file structure. 

244 BADCHKSUM Bad checksum on header file. 

245 BADFILEHDR Bad file header. 

246 BADIRECTORY Bad directory file. 

247 FILNOTCNTG Invalid program image format. 

248 ENDOFFILE Premature end of file encountered. 

249 BADFILENAME Bad file name given. 

24A BUFFEROVF Program image does not fit in available memory. 
?4B CTRLERR Boot device I/O error. 

24C DEVINACT Failed to initialize boot device. 

?4D DEVOFFLINE Device is off line. 

?4E MEMERR Memory initialization error. 

?4F SCBINT Unexpected SCB exception or machine check. 
250 SCB2NDINT Unexpected exception after starting program image. 
251 NOROM No valid ROM image found. 

252 NOSUCHNODE No response from load server. 

253 INSFMAPREG The Q22-bus map initialization failed. 

254 RETRY No devices bootable, retrying. 

255 IVDEVNAM Invalid device name. 

256 DRVERR Drive error. 


Error Messages C-3 


Error Messages 


C.4 Console Error Messages 


C.4 Console Error Messages 


These error messages are issued in response to a console command that has 


error(s). 


Table C-3 Console Error Messages 


Code Message Description 

261 CORRUPTION The console program database has been corrupted. 

262 ILLEGAL REFERENCE Illegal reference. Either the requested reference would violate 
virtual memory protection, the address is not mapped, the reference 
is invalid in the specified address space, or the value is invalid in the 
specified destination. 

263 ILLEGAL COMMAND The command string cannot be parsed. 

264 INVALID DIGIT A number has an invalid digit. 

265 LINE TOO LONG The command was too large for the console to buffer. The message is 
issued only after receipt of the terminating Return. 

266 ILLEGAL ADRRESS The address specified falls outside the limits of the address space. 

267 VALUE TOO LARGE The value specified does not fit in the destination. 

268 QUALIFIER CONFLICT Qualifier conflict (for example, two different data sizes are specified 
for an EXAMINE command). 

269 UNKNOWN QUALIFIER _ The switch is unrecognized. 

26A UNKNOWN SYMBOL The symbolic address in an EXAMINE or DEPOSIT command is 
unrecognized. 

26B CHECKSUM The command or data checksum of an X command is incorrect. If 
the data checksum is incorrect, this message is issued, and is not 
abbreviated to "Illegal command." 

26C HALTED The operator entered a HALT command. 

26D FIND ERROR A FIND command failed either to find the RPB or 128 KB of good 
memory. 

?6E TIME OUT During an X command, data failed to arrive in the time expected (60 
seconds). 

?6F MEMORY ERROR A machine check occurred with a code indicating a read or write 
memory error. 

270 UNIMPLEMENTED Unimplemented function. 

271 NO VALUE QUALIFIER Qualifier does not take a value. 

272 AMBIGUOUS There were not enough unique characters to determine the qualifier. 

QUALIFIER 
273 VALUE QUALIFIER Qualifier requires a value. 
274 TOO MANY Too many qualifiers supplied for this command. 
QUALIFIERS 
275 TOO MANY Too many arguments supplied for this command. 
ARGUMENTS 
276 AMBIGUOUS There were not enough unique characters to determine the 
COMMAND command. 
277 TOO FEW ARGUMENTS sInsufficient arguments supplied for this command. 
278 TYPEAHEAD The typeahead buffer overflowed. 
OVERFLOW 
(continued on next page) 
C-4 Error Messages 


Error Messages 
C.4 Console Error Messages 


Table C-3 (Cont.) Console Error Messages 


Code Message Description 

?79 FRAMING ERROR A framing error was detected on the console serial line. 
27A OVERRUN ERROR An overrun error was detected on the console serial line. 
?7B SOFT ERROR A soft error occurred. 

27C HARD ERROR A hard error occurred. 

27D MACHINE CHECK A machine check occurred. 
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Machine State on Powerup 


This appendix describes the state of the KA680 after a power-up halt. 


The descriptions in this section assume a machine with no errors, the machine 
has just been turned on, and only the power-up diagnostics have been run. The 
state of the machine is not defined if individual diagnostics are run or during any 
other halts other than a power-up halt (SAVPSL<13:8>(RESTART_CODE) = 38). 


The following sections describe data structures that are guaranteed to be constant 
over future versions of the KA680 firmware. Placement and/or existence of any 
other structure(s) is not implied. 


D.1 Main Memory Layout and State 


Main memory is tested and initialized by the firmware on powerup. Figure D-1 
is a diagram of how main memory is partitioned after diagnostics. 


Figure D-1 Memory Layout after Power-up Diagnostics 
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D.1.1 Reserved Main Memory 


In order to build the scatter/gather map and the bitmap, the firmware attempts to 
find a physically contiguous page-aligned 176 KB block of memory at the highest 
possible address that has no multiple bit errors. Single bit errors are tolerated in 
this section. 
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Of the 176 KB, the upper 32 KB are dedicated to the Q22-bus scatter/gather 
map, as shown in Figure F-1. Of the lower portion, up to 128 KB at the bottom 
of the block is allocated to the PFN (page frame number) bitmap. The size of 
the PFN bitmap is dependent on the extent of physical memory. Each bit in 
the bitmap maps one page (512 bytes) of memory. The remainder of the block 
between the bitmap and scatter/gather map (a minimum of 16 KB) is allocated 
for the firmware. 


D.1.1.1 PFN Bitmap 
The PFN bitmap is a data structure that indicates which pages in memory are 
deemed usable by operating systems. The bitmap is built by the diagnostics as 
an outcome of the memory tests on powerup. The bitmap always starts on a page 
boundary. The bitmap requires 1 KB for every 4 MB of main memory; hence, an 8 
MB system requires 2 KB, 16 MB requires 4 KB, 32 MB requires 8 KB, and a 64 
MB requires 16 KB. The bitmap does not map itself or anything above it. There 
may be memory above the bitmap that has both good and bad pages. 


Each bit in the PFN bitmap corresponds to a page in main memory. There is 

a one-to-one correspondence between a page frame number (origin 0) and a bit 
index in the bitmap. A one in the bitmap indicates that the page is "good" and 
can be used. A zero indicates that the page is "bad" and should not be used. By 
default, a page is flagged "bad" if a multiple bit error occurs when referencing 
the page. Single bit errors, regardless of frequency, will not cause a page to be 
flagged "bad." 


The PFN bitmap is protected by a checksum stored in the NVRAM. The checksum 
is a simple byte wide, two’s complement checksum. The sum of all bytes in the 
bitmap and the bitmap checksum should result in zero. Operating systems that 
modify the bitmap are encouraged to update this checksum to facilitate diagnosis 
by service personnel. 


D.1.1.2 Scatter/Gather Map 
On powerup, the scatter/gather map is initialized by the firmware to map to the 
first 4 MB of of main memory. Main memory pages will not be mapped if there 
is a corresponding page in Q22—bus memory, or if the page is marked bad by the 
PFN bitmap. 


On a processor halt other than powerup, the contents of the scatter/gather map is 
undefined, and is dependent on operating system usage. 


Operating systems should not move the location of the scatter/gather map, and 
should access the map only on aligned longwords through the local I/O space of 
20088000 to 2008FFFC, inclusive. The Q22—bus map base register, (QMBR) is set 
up by the firmware to point to this area, and should not be changed by software. 


D.1.1.3 Firmware "Scratch Memory" 
This section of memory is reserved for the firmware. However, it is used only 
after successful execution of the memory diagnostics and initialization of the PFN 
bitmap and scatter/gather map. This memory is primarily used for diagnostic 
purposes. 
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D.1.2 Contents of Main Memory 


The contents of main memory are undefined after the diagnostics have run. 
Typically, nonzero test patterns will be left in memory. 


The diagnostics will "scrub" all main memory so that no power-up induced errors 
remain in the memory system. On the KA680 memory subsystem, the state of 
the ECC bits and the data bits are undefined on initial powerup. This can result 
in single and multiple bit errors if the locations are read before written, because 
the ECC bits are not in agreement with their corresponding data bits. An aligned 
longword write to every location (done by diagnostics) eliminates all power-up 
induced errors. 


D.2 Memory Controller Registers 


The KA680 firmware assigns bank numbers to the MEMCONn registers in 
ascending order, without attempting to disable physical banks that contain 
errors. High order unused banks are set to zero. Error loggers should capture 
the following bits from each MEMCONn register: 


MEMCONn <31> (bank enable bit). Since the firmware always assigns banks in 
ascending order, knowing which banks are enabled is sufficient information to 
derive the bank numbers. MEMCONn <1:0> (bank usage). This field determines 
the size of the banks on the particular memory board. 


Additional information should be captured from the NMCDSR, MOAMR, MSER, 
and MEAR as needed. 


D.2.1 On-chip Cache 


The CPU on-chip cache is tested during the power-up diagnostics, flushed, 
and then turned on. The cache is also turned on by the BOOT and the INIT 
command. 


D.2.2 Translation Buffer 


The CPU translation buffer is tested by diagnostics on powerup, but is not used 
by the firmware because it runs in physical mode. The translation buffer can be 
invalidated by using PR$_TBIA, IPR 57. 


D.2.3 Halt-Protected Space 


On the KA680, halt-protected space spans the 512 KB FEPROM from E0040000 
to EOO7FFFF. The firmware always runs in halt-protected space. When passing 
control to the bootstrap, the firmware exits the halt-protected space. Therefore, 

if halts are enabled, and the halt line is asserted, the processor will halt before 

booting. 
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MOP Support 


This appendix describes the maintenance operation protocol (MOP) support 
features in the KA680 firmware. 


E.1 Network "Listening" 


While the KA680 is waiting for a load volunteer during bootstrap, it "listens" on 
the network for other maintenance messages directed to the node and periodically 
identifies itself at the end of each 8- to 12-minute interval prior to a bootstrap 
retry. In particular, this "listener" supplements the MOP functions of the VMB 
load requester typically found in bootstrap firmware and supports: 


¢ A remote console server that generates COUNTERS messages in response to 
REQ_COUNTERS messages, unsolicited SYSTEM_ID messages every 8 to 12 
minutes, and solicited SYSTEM_ID messages in response to REQUEST_ID 
messages as well as recognition of BOOT messages. 


¢ A loopback server that responds to Ethernet LOOPBACK messages by 
echoing the message to the requester. 


e An IEEE 802.2 responder that replies to both XID and TEST messages. 


During network bootstrap operation, the KA680 complies with the requirements 
defined in the "NI Node Architecture Specification" for a primitive node. The 
firmware listens only to MOP "Load/Dump," MOP "Remote Console," Ethernet 
"Loopback Assistance," and IEEE 802.3 XID/TEST messages (listed in 

Table E—4) directed to the Ethernet physical address of the node. All other 
Ethernet protocols are filtered by the network device driver. 


The MOP functions and message types that are supported by the KA680 are 
summarized in the following tables. 
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Table E-1 KA680 Network Maintenance Operations Summary 


Function Role Transmit Receive 


MOP Ethernet and IEEE 802.3 Messages ' 


Dump Requester — — 
Server — — 
Load Requester REQ PROGRAM? to solicit VOLUNTEER 
REQ _MEM_LOAD to solicit & ACK MEM_LOAD 
or MEM_ 
LOAD_ 
w_XFER 
or PARAM _ 
LOAD_w_ 
XFER 
Server — > 
Console Requester — — 
Server COUNTERS in response to REQ_ 
COUNTERS 
SYSTEM_ID? in response to REQUEST_ 
ID 
BOOT 
Loopback Requester — — 
Server LOOPED_DATA* in response to LOOP_DATA 


IEEE 802.2 Messages° 


Exchange ID Requester — — 


Server XID_RSP in response to XID_CMD 
Test Requester — — 
Server TEST_RSP in response to TEST_CMD 


1 All unsolicited messages are sent in Ethernet (MOP V3) and IEEE 802.2 (MOP V4) until the MOP 
version of the server is known. All solicited messages are sent in the format used for the request. 


The initial REQ_PROGRAM message is sent to the dumpload multicast address. If an assistance 
VOLUNTEER message is received, then the responder’s address is used as the destination to repeat 
the REQ_PROGRAM message and for all subsequent REQ. MEM_LOAD messages. 


3SYSTEM_ID messages are sent every 8 to 12 minutes to the remote console multicast address. On 
receipt of a REQUEST_ID message, they are sent to the initiator. 


4LOOPED_DATA messages are sent in response to LOOP_DATA messages. These messages are 
actually in Ethernet LOOP TEST format, not in MOP format. When sent in Ethernet, frames omit 
the additional length field (padding is disabled). 


5TEEE 802.2 support of XID and TEST is limited to Class 1 operations. 
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MOP Support 


E.1 Network "Listening" 


Message Type Message Fields 
DUMP/LOAD 
MEM_LOAD_w_ Code Load # Load addr Image data Xfer addr 
XFER 00 nn aa-aa-aa-aa None aa-aa-aa-aa 
MEM_LOAD Code Load # Load addr Image data 
02 nn aa-aa-aa-aa dd-... 
REQ PROGRAM Code Device Format Program SWID? Procesr Info 
08 25 LQA_ 01V3 C-17 + 00 Sys (see SYSTEM_ID) 
49 04 V4 02 C-128 * 
SGEC Sys If C[1] 
>00 Len 
00 No 
ID 
FF OS 
FE 
Maint 
REQ _MEM_LOAD Code Load # Error 
OA nn ee 
PARM_LOAD_w_ Code Load # Prm typ Prmlen Prm val Xfer addr 
XFER 14 nn 1 I-16 Target name ! aa-aa-aa-aa 
02 1-06 Target addr ! 
03 1-16 Host name ! 
04 1-06 Host addr ! 
05 OA Host time 4 
06 08 Host time ” 
00 End 
VOLUNTEER Code 
03 


™MOP V3.0 only. 
2MOP x4.0 only. 


3 Software ID field is loaded from the string stored in the 40-byte field, RPB$T_FILE, of the RPB on a solicited boot. 


(continued on next page) 
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Table E-2 (Cont.) Supported MOP Messages 
( ) PP REMOTE CONSOLE 


REQUEST_ID Code Rsrvd Recpt # 
05 xx nn-nn 
SYSTEM_ID Code Rsrvd Recpt # Info type Info len Info value 
07 XX nn-nn 01-00 Version 03 04-00-00 
or 02-00 Functions 02 00-59 
00-00 07-00 HW addr 06 ee-ee-ee-ee-ee-ee 
64-00 Device 01 25 or 49 
90-01 Datalink 01 01 
91-01 Bufr size 02 06-04 
REQ COUNTERS Code Recpt # 
09 nn-nn 
COUNTERS Code Recpt # Counter block 
OB nn-nn 
BOOT * Code Verification Procesr Control Dev ID SW ID? Script 
06 VV-VV-VV-VV-VV-VV- 00 Sys XX C-17 (see ID? 
VV-vVV REQ_ C-128 
PROGRAM) 
LOOPBACK 
LOOP_DATA Skpent Skipped bytes Function Forward addr Data 
bb-... 00-02 Forward ee-ee-ee-ee-ee-ee dd-... 
nn-nn data 
LOOPED_DATA Skpent Skipped bytes Function Recpt # Data 
bb-... 00-01 Reply nn-nn dd-... 
nn-nn 
IEEE 802.2 
XID_CMD/RSP Form Class Rx window size (K) 
81 01 00 


TEST_CMD/RSP 


Optional data. 


2MOP x4.0 only. 


3 Software ID field is loaded from the string stored in the 40-byte field, RPB$T_FILE, of the RPB on a solicited boot. 


44 BOOT message is not verified, because in this context, a boot is already in progress. However, a received BOOT 
message will cause the boot backoff timer to be reset to it’s minimum value. 
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Table E-3 Ethernet and IEEE 802.3 Packet Headers 


Ethernet MOP Message Format (MOP V3) 


Dest_address Sre_address Prot Len MOP msg Pad 
dd-dd-dd-dd-dd- SS-SS-SS-SS-SS- 60-01 nn- dd-... XX-... 
dd ss nn 
60-02 nn- dd-... 
nn 
90-00 dd-... 
IEEE 802.3 SNAP SAP MOP Message Format (MOP V4) 
Dest_address Sre_address Len DSAP SSAP Ctl P_ID MOP_ 
msg 
dd-dd-dd-dd-dd- SS-SS-SS-SS-SS- nn-nn AA AA 03 08-00-2B-60-01 dd-... 
dd ss 08-00-2B-60-02 
08-00-2B-90-00 
IEEE 802.3 XID/TEST Message Format (MOP V4) 
Dest_address Src_address Len DSAP SSAP Ctl! Data 
dd-dd-dd-dd-dd- SS-SS-SS-SS-SS- nn-nn aa bb ce ff-tt-ss (XID) 
dd ss Optional data (TEST) 


1XID and TEST messages are identified in the IEEE 802.2 control field with binary 101x1111 and 
111x0011, respectively. "x" denotes the Poll/Final bit that gets echoed in the response. 


Table E-4 MOP Multicast Addresses and Protocol Specifiers 


Function Address IEEE Prefix’ Protocol Owner 
Dump/Load AB-00-00-01-00-00 08-00-2B 60-01 Digital 
Remote Console AB-00-00-02-00-00 08-00-2B 60-02 Digital 
Loopback Assistance CF-00-00-00-00-00 2 08-00-2B 90-00 Digital 


1MOP 4.0 only. 
2Not used. 
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E.2 MOP Counters 


The following counters are kept for the Ethernet boot channel. All counters are unsigned 
integers. V4 counters roll over on overflow. All V3 counters "latch" at their maximum value 

to indicate overflow. Unless otherwise stated, all counters include both normal and multicast 
traffic. Furthermore, they include information for all protocol types. Frames received and bytes 
received counters do not include frames received with errors. Table E—5 displays the byte lengths 
and ordering of all the counters in both MOP Versions 3.0 and 4.0. 


Table E-5 MOP Counter Block 


Name 


V3 
Off Len 


V4 
Off Len 


Description 


TIME_SINCE_ 
CREATION 


Rx_BYTES 


Tx_BYTES 


E-6 MOP Support 


00 2 


02 4 


06 4 


00 16 


10 8 


18 8 


Time since last zeroed. The time 
that has elapsed since the counters 
were last zeroed. Provides a frame 
of reference for the other counters by 
indicating the amount of time they 
cover. For MOP V3, this time is the 
number of seconds. MOP V4 uses the 
UTC binary relative time format. 


Bytes received. The total number 
of user data bytes successfully received. 
This does not include Ethernet data link 
headers. This number is the number of 
bytes in the Ethernet data field, which 
includes any padding or length fields 
when they are enabled. These are bytes 
from frames that passed hardware 
filtering. When the number of frames 
received is used to calculate protocol 
overhead, the overhead plus bytes 
received provides a measurement of the 
amount of Ethernet bandwidth (over 
time) consumed by frames addressed to 
the local system. 


Bytes sent. The total number of user 
data bytes successfully transmitted. 
This does not include Ethernet data 
link headers or data link generated 
retransmissions. This number is the 
number of bytes in the Ethernet data 
field, which includes any padding or 
length fields when they are enabled. 
When the number of frames sent is 
used to calculate protocol overhead, the 
overhead plus bytes sent provides a 
measurement of the amount of Ethernet 
bandwidth (over time) consumed by 
frames sent by the local system. 
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Name 


V3 


Off Len 


Off Len 


V4 


Description 


Rx_FRAMES 


Tx_FRAMES 


Rx_MCAST_BYTES 


Rx_MCAST_FRAMES 


Tx_INIT_DEFFERED 


Tx_ONE_COLLISION 


0A 


OE 


12 


16 


1A 


1E 


4 


20 


28 


30 


38 


40 


48 


8 


Frames received. The total number 
of frames successfully received. These 
are frames that passed hardware 
filtering. Provides a gross measurement 
of incoming Ethernet usage by the local 
system. Provides information used to 
determine the ratio of the error counters 
to successful transmits. 


Frames sent. The total number of 
frames successfully transmitted. This 
does not include data link generated 
retransmissions. Provides a gross 
measurement of outgoing Ethernet 
usage by the local system. Provides 
information used to determine the 
ratio of the error counters to successful 
transmits. 


Multicast bytes received. The 
total number of multicast data bytes 
successfully received. This does not 
include Ethernet data link headers. 
This number is the number of bytes in 
the Ethernet data field. In conjunction 
with total bytes received, provides a 
measurement of the percentage of this 
system’s receive bandwidth (over time) 
that was consumed by multicast frames 
addressed to the local system. 


Multicast frames received. The 
total number of multicast frames 
successfully received. In conjunction 
with total frames received, provides a 
gross percentage of the Ethernet usage 
for multicast frames addressed to this 
system. 


Frames sent, ! initially deferred. 
The total number of times that a frame 
transmission was deferred on its first 
transmission attempt. In conjunction 
with total frames sent, measures 
Ethernet contention with no collisions. 


Frames sent ', single collision. The 
total number of times that a frame was 
successfully transmitted on the second 
attempt after a normal collision on 

the first attempt. In conjunction with 
total frames sent, measures Ethernet 
contention at a level where there are 
collisions but the backoff algorithm still 
operates efficiently. 


Only one of these three counters will be incremented for a given frame. 


(continued on next page) 
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Table E—5 (Cont.) MOP Counter Block 


V3 v4 
Name Off Len OffLen Description 


Tx_MULTI_COLLISION 22 4 50 8 Frames sent', multiple collisions. 
The total number of times that a frame 
was successfully transmitted on the 
third or later attempt after normal 
collisions on previous attempts. In 
conjunction with total frames sent, 
measures Ethernet contention at a 
level where there are collisions and the 
backoff algorithm no longer operates 
efficiently. No SINGLE FRAME IS COUNTED 
IN MORE THAN ONE OF THE ABOVE THREE 
COUNTERS. 


TxFAIL_COUNT 26 2 - Send failure count. * The total 
number of times a transmit attempt 
failed. Each time the counter is 
incremented, a type of failure is 
recorded. When read-counter function 
reads the counter, the list of failures is 
also read. When the counter is set to 
zero, the list of failures is cleared. In 
conjunction with total frames sent, 
provides a measure of significant 
transmit problems. TxFAIL_BITMAP 
contains the possible reasons. 


TxFAIL_BITMAP 2C 2 - Send failure reason bitmap. ” 
This bitmap lists the types of transmit 
failures that occurred as summarized 
below. 


0 - Excessive collisions 

1 - Carrier detect failed 

2 - Short circuit 

3 - Open circuit 

4 - Frame too long 

5 - Remote failure to defer 


TxFAIL_EXCESS_COLLS-~ - - 58 8 Send failure - Excessive collisions. 
Exceeded the maximum number of 
retransmissions due to collisions. 
Indicates an overload condition on 
the Ethernet. 


TxFAIL_CARIER_CHECK - - 60 8 Send failure - Carrier check failed. 
The data link did not sense the receive 
signal that is required to accompany 
the transmission of a frame. Indicates 
a failure in either the transmitting or 
receiving hardware. Could be caused by 
either transceiver, transceiver cable, or 
a babbling controller that has been cut 
off. 


Only one of these three counters will be incremented for a given frame. 


2V3 send/receive failures are collapsed into one counter with bitmap indicating which failures 
occurred. 
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Name 


V3 


Off Len 


V4 
Off Len 


Description 


TxFAIL_SHRT_CIRCUIT 


TxFAIL_OPEN_CIRCUIT 


TxFAIL_LONG_FRAME 


TxFAIL_REMOTE_ 
DEFER 


RxFAIL_COUNT 


RxFAIL_BITMAP 


2A 


2C 


68 8 


70 8 


78 8 


80 8 


Send failure - Short circuit. ? There 
is a short somewhere in the local area 
network coaxial cable, or the transceiver 
or controller/transceiver cable has 
failed. This indicates a problem either 
in local hardware or global network. 
The two can be distinguished by 
checking to see if other systems are 
reporting the same problem. 


Send failure - Open circuit. 7 There 
is a break somewhere in the local area 
network coaxial cable. This indicates 
a problem either in local hardware 
or global network. The two can be 
distinguished by checking to see if 
other systems are reporting the same 
problem. 


Send failure - Frame too long. ? 
The controller or transceiver cut off 
transmission at the maximum size. 
This indicates a problem with the local 
system. Either it tried to send a frame 
that was too long or the hardware cutoff 
transmission too soon. 


Send failure - Remote failure to 
defer. > A remote system began 
transmitting after the allowed window 
for collisions. This indicates either 
a problem with some other system’s 
carrier sense or a weak transmitter. 


Receive failure count. ” The total 
number of frames received with some 
data error. Includes only data frames 
that passed either physical or multicast 
address comparison. This counter 
includes failure reasons in the same 
way as the send failure counter. In 
conjunction with total frames received, 
provides a measure of data-related 
receive problems. RxFAIL_BITMAP 
contains the possible reasons. 


Receive failure reason bitmap. ” 
This bitmap lists the types of receive 
failures that occurred as summarized 
below. 


0 - Block check failure 
1 - Framing error 
2 - Frame too long 


2V73 send/receive failures are collapsed into one counter with bitmap indicating which failures 


occurred. 
3 Always zero. 
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Table E—5 (Cont.) MOP Counter Block 


Name 


Off Len 


V3 


V4 
Off Len 


Description 


RxFAIL_BLOCK_CHECK 


RxFAIL_FRAMING_ERR 


RxFAIL_LONG_FRAME 


UNKNOWN_ 
DESTINATION 


DATA_OVERRUN 


NO_SYSTEM_BUFFER 


2E 


30 


32 


88 8 


90 8 


98 8 


AO 8 


A8& 8 


BO 8 


Receive failure - Block check error. 
A frame failed the CRC check. This 
indicates several possible failures, such 
as EMI, late collisions, or improperly 
set hardware parameters. 


Receive failure - Framing error. 
The frame did not contain an integral 
number of 8-bit bytes. This indicates 
several possible failures, such as 
EMI, late collisions, or improperly 
set hardware parameters. 


Receive failure - Frame too long.’ 
The frame was discarded because it 
was outside the Ethernet maximum 
length and could not be received. 
This indicates that a remote system 
is sending invalid length frames. 


Unrecognized frame destination. 
The number of times a frame was 
discarded because there was no portal 
with the protocol type or multicast 
address enabled. This includes frames 
received for the physical address, 
the broadcast address, or a multicast 
address. 


Data overrun. The total number of 
times the hardware lost an incoming 
frame because it was unable to keep 
up with the data rate. In conjunction 
with total frames received, provides a 
measure of hardware resource failures. 
The problem reflected in this counter is 
also captured as an event. 


System buffer unavailable? The 
total number of times no system buffer 
was available for an incoming frame. In 
conjunction with total frames received, 
provides a measure of system buffer- 
related receive problems. The problem 
reflected in this counter is also captured 
as an event. This can be any buffer 
between the hardware and the user 
buffers (those supplied on Receive 
requests). Further information as 
to potential different buffer pools is 
implementation-specific. 


3 Always zero. 
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Description 


V3 V4 
Name Off Len Off Len 
NO_USER_BUFFER 34 2 B8 8 
FAIL_COLLIS_DETECT - - CoO 8 


User buffer unavailable. ? The 
total number of times no user buffer 
was available for an incoming frame 
that passed all filtering. These are the 
buffers supplied by users on Receive 
requests. In conjunction with total 
frames received, provides a measure of 
user buffer-related receive problems. 
The problem reflected in this counter is 
also captured as an event. 


Collision detect check failure. The 
approximate number of times that 
collision detect was not sensed after a 
transmission. If this counter contains a 
number roughly equal to the number of 
frames sent, either the collision detect 
circuitry is not working correctly or the 
test signal is not implemented. 


3 Always zero. 
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This appendix describes the specifications for the Q22—bus. 


F.1 Introduction 


The Q22-bus, also known as the extended LSI-11 bus, is the low-end member of 
Digital’s bus family. 


The Q22-bus consists of 42 bidirectional and 2 unidirectional signal lines. These 
form the lines along which the processor, memory, and I/O devices communicate 
with each other. 


Addresses, data, and control information are sent along these signal lines, some 
of which contain time-multiplexed information. The lines are divided as follows: 


¢ 16 multiplexed data/address lines — BDAL<15:00> 
¢ 2 multiplexed address/parity lines — BDAL<17:16> 
¢ 4 extended address lines — BDAL<21:18> 


e 6 data transfer control lines — BBS7, BDIN, BDOUT, BRPLY, BSYNC, 
BWTBT 


¢ 6 system control lines — BHALT, BREF, BEVNT, BINIT, BDCOK, BPOK 


¢ 10 interrupt control and direct memory access control lines — BIAKO, BIAKI, 
BIRQ4, BIRQ5, BIRQ6, BIRQ7, BDMGO, BDMR, BSACK, BDMGI 


In addition, a number of power, ground, and space lines are defined for the bus. 
Refer to Table F—1 for a detailed description of these lines. 


The discussion in this appendix applies to the general 22-bit physical address 
capability. All modules used with the KA680 CPU module must use 22-bit 
addressing. 


Most Q22-bus signals are bidirectional and use terminations for a negated 
(high) signal level. Devices connect to these lines by way of high-impedance bus 
receivers and open collector drivers. The asserted state is produced when a bus 
driver asserts the line low. 


Although bidirectional lines are electrically bidirectional (any point along the 
line can be driven or received), certain lines are functionally unidirectional. 
These lines communicate to or from a bus master (or signal source), but not 
both. Interrupt acknowledge (BIAK) and direct memory access grant (BDMG) 
signals are physically unidirectional in a daisy-chain fashion. These signals 
originate at the processor output signal pins. Each is received on device input 
pins (BIAKI or BDMGI) and is conditionally retransmitted through device output 
pins (BIAKO or BDMGO). These signals are received from higher priority devices 
and are retransmitted to lower priority devices along the bus, establishing the 
position-dependent priority scheme. 
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F.1.1 Master/Slave Relationship 


Communication between devices on the bus is asynchronous. A master/slave 
relationship exists throughout each bus transaction. Only one device has control 
of the bus at any one time. This controlling device is called the bus master, or 
arbiter. The master device controls the bus when communicating with another 
device on the bus, called the slave. 


The bus master (typically the processor or a DMA device) initiates a bus 
transaction. The slave device responds by acknowledging the transaction in 
progress and by receiving data from, or transmitting data to, the bus master. 
Q22-bus control signals transmitted or received by the bus master or bus slave 
device must complete the sequence according to bus protocol. 


The processor controls bus arbitration (that is, which device becomes bus master 
at any given time). A typical example of this master-slave relationship is a disk 
drive as master, transferring data to memory as slave. Communication on the 
Q22-bus is interlocked so that, for certain control signals issued by the master 
device, there must be a response from the slave in order to complete the transfer. 
It is the master/slave signal protocol that makes the Q22—bus asynchronous. The 
asynchronous operation precludes the need for synchronizing with, and waiting 
for, clock pulses. 


Since completion of the bus cycle by the bus master requires response from the 
slave device, each bus master must include a timeout error circuit that aborts the 
bus cycle if the slave does not respond to the bus transaction within 10 ps. The 
actual time before a timeout error occurs must be longer than the reply time of 
the slowest peripheral or memory device on the bus. 


F.2 Q22-—bus Signal Assignments 


Table F—1 lists the data and address signal assignments. Table F—2 lists 
the control signal assignments. Table F—3 lists the power and ground signal 
assignments. Table F—4 lists the spare signal assignments. 


Table F-1 Data and Address Signal Assignments 


Data and Address Signal Pin Assignment 
BDALO AU2 
BDAL1 AV2 
BDAL2 BE2 
BDAL3 BF2 
BDAL4 BH2 
BDAL5 BJ2 
BDAL6 BK2 
BDAL7 BL2 
BDAL8 BM2 
BDAL9 BN2 
BDAL10 BP2 
BDAL11 BR2 


(continued on next page) 
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Table F-1 (Cont.) Data and Address Signal Assignments 


Data and Address Signal Pin Assignment 
BDAL12 BS2 
BDAL13 BT2 
BDAL14 BU2 
BDAL15 BV2 
BDAL16 AC1 
BDAL17 AD1 
BDAL18 BC1 
BDAL19 BD1 
BDAL20 BE1 
BDAL21 BF1 


Table F-2 Control Signal Assignments 


Control Signal Pin Assignment 


Data Control 


BDOUT AE2 
BRPLY AF2 
BDIN AH2 
BSYNC AJ2 

BWTBT AK2 
BBS7 AP2 


Interrupt Control 


BIRQ7 BP1 
BIRQ6 ABI 
BIRQ5 AAI 
BIRQ4 AL2 
BIAKO AN2 
BIAKI AM2 
DMA Control 

BDMR AN1 
BSACK BN1 
BDMGO AS2 
BDMGI AR2 


(continued on next page) 
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Table F-2 (Cont.) Control Signal Assignments 


Control Signal Pin Assignment 


System Control 


BHALT AP1 
BREF ARI 
BEVNT BR1 
BINIT AT2 
BDCOK BAI 
BPOK BB1 


Table F-3 Power and Ground Signal Assignments 


Power and Ground Pin Assignment 
+5 B (battery) or +12 B (battery) AS1 
+12B BS1 
+5 B AV1 
+5 AA2 
+5 BA2 
+5 BV1 
+12 AD2 
+12 BD2 
+12 AB2 
—12 AB2 
-12 BB2 
GND AC2 
GND AJ1 
GND AM1 
GND ATI 
GND BC2 
GND BJ1 
GND BM1 
GND BT1 


Table F-4 Spare Signal Assignments 


Spare Pin Assignment 
SSparel AE1 
SSpare3 AH1 


(continued on next page) 
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Table F—4 (Cont.) Spare Signal Assignments 
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F.2 Q22—bus Signal Assignments 


Spare Pin Assignment 
SSpare8 BH1 
SSpare2 AF1 
MSpareA AK1 
MSpareB AL1 
MSpareB BK1 
MSpareB BLI1 
PSparel AU1 
ASpare2 BU1 


F.3 Data Transfer Bus Cycles 


Data transfer bus cycles, executed by bus master devices, transfer 32-bit words 
or 8-bit bytes to or from slave devices. In block mode, multiple words can be 
transferred to sequential word addresses, starting from a single bus address. 
Table F—5 lists the data transfer bus cycles. 


Table F-5 Data Transfer Operations 


Function (with 
respect to the bus 


Bus Cycle Definition master) 

DATI Data word input Read 

DATO Data word output Write 

DATOB Data byte output Write/byte 

DATIO Data word input/output Read-modify-write 

DATIOB Data word input/byte output Read-modify-write 
byte 

DATBI Data block input Read block 

DATBO Data block output Write block 


The bus signals listed in Table F—6 are used in the data transfer operations 


described in Table F—5. 
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Table F-6 Bus Signals for Data Transfers 


Signal Definition Function 


BDAL<21:00> L 22 data/address lines BDAL<15:00> L are 
used for word and byte 
transfers. BDAL<17:16> 
L are used for extended 
addressing, memory parity 
error (16), and memory 
parity error enable (17) 
functions. BDAL<21:18> 
L are used for extended 
addressing beyond 256 


Kbytes. 

BSYNC L Bus cycle control Indicates bus transaction 
in progress. 

BDIN L Data input indicator Strobe signals. 

BDOUT L Data output indicator Strobe signals. 

BRPLY L Slave’s acknowledge of bus cycle Strobe signals. 

BWTBT L Write/byte control Control signals. 

BBS7 I/O device select Indicates address is in the 
I/O page. 


Data transfer bus cycles can be reduced to five basic types: DATI, DATO(B), 
DATIO(B), DATBI, and DATBO. These transactions occur between the bus 
master and one slave device selected during the addressing part of the bus cycle. 


F.3.1 Bus Cycle Protocol 


Before initiating a bus cycle, the previous bus transaction must have been 
completed (BSYNC L negated) and the device must become bus master. The bus 
cycle can be divided into two parts — addressing and data transfer. 


¢ During addressing, the bus master outputs the address for the desired slave 
device, memory location, or device register. The selected slave device responds 
by latching the address bits and holding this condition for the duration of the 
bus cycle until BSYNC L becomes negated. 


¢ During the data transfer, the actual data transfer occurs. 
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F.3.2 Device Addressing 


Device addressing of a data transfer bus cycle comprises an address setup and 
deskew time, and an address hold and deskew time. During address setup and 
deskew time, the bus master does the following operations: 


e Asserts BDAL<21:00> L with the desired slave device address bits 
e Asserts BBS7 L if a device in the I/O page is being addressed 
e Asserts BWTBT L if the cycle is a DATO(B) or DATBO bus cycle 


During this time, the address (BBS7 L) and BWTBT L signals are asserted at 
the slave bus receiver for at least 75 ns before BSYNC goes active. Devices in 
the I/O page ignore the 9 high-order address bits BDAL<21:13>, and instead, 
decode BBS7 L along with the 13 low-order address bits. An active BWTBT L 
signal during address set-up time indicates that a DATO(B) or DATBO operation 
follows, while an inactive BWTBT L indicates a DATI, DATBI, or DATIO(B) 
operation. 


The address hold and deskew time begins after BSYNC L is asserted. 


The slave device uses the active BSYNC L bus received output to clock BDAL 
address bits BBS7 L, and BWTBT L into its internal logic. BDAL<21:00> L, 
BBS7 L, and BWTBT L remain active for 25 ns minimum after the BSYNC L bus 
receiver goes active. BSYNC L remains active for the duration of the bus cycle. 


Memory and peripheral devices are addressed similarly, except for the way the 

slave device responds to BBS7 L. Addressed peripheral devices must not decode 
address bits on BDAL<21:13> L. Addressed peripheral device can respond to a 

bus cycle when BBS7 L is asserted (low) during the addressing of the cycle. 


When asserted, BBS7 L indicates that the device address resides in the I/O 
page (the upper 4K address space). Memory devices generally do not respond 
to addresses in the I/O page; however, some system applications may permit 
memory to reside in the I/O page for use as DMA buffers, read-only memory 
bootstraps, and diagnostics. 


DATI 


The DATI bus cycle (Figure F—1) is a read operation. During DATI, data is 
input to the bus master. Data consists of 16-bit word transfers over the bus. 
During data transfer of the DATI bus cycle, the bus master asserts BDIN L 100 
ns minimum after BSYNC L is asserted. The slave device responds to BDIN L 
active as follows: 


e Asserts BRPLY L between 0 ns (minimum) and 8 ns (maximum, to avoid bus 
timeout) after receiving BDIN L, and 125 ns (maximum) before BDAL bus 
driver data bits are valid 


e Asserts BDAL<21:00> L with the addressed data and error information 0 ns 
(minimum) after receiving BDIN, and 125 ns (maximum) after assertion of 
BRPLY 
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Figure F-1 DATI Bus Cycle 


Bus Master Slave 
(Processor or Device) Memory Device 


Address Device or Memory 

¢ Asserts BDAL <21:00>L with 
address 

¢ Asserts BBS7 if the address 
is in the I/O page 

e Asserts BSYNC L “ 


~~ = Decode Address 
e Store "Device Selected" 


operation 
Request Data oS 
e Remove the address from 
BDAL>21:00>L 
* Negate BBS7 L 
° Assert BDIN L Fees 
~~~ 2 Input Data 
e Place data on BDAL <15:00> L 
e Assert BRPLY L 
Terminate Input Transfer 
¢ Accept data and respond 
by negating BDIN L 
Terminate Bus Cycle eee Operation Completed 
e Negate BSYNC L ee e Negate BRPLY L 
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When the bus master receives BRPLY L, it does the following: 


¢ Waits at least 200 ns deskew time, then accepts input data at BDAL<17:00> 
L bus receivers. BDAL <17:16> L are used for transmitting parity errors to 
the master 


¢ Negates BDIN L 200 ns (minimum) to 2 ps (maximum) after BRPLY L goes 
active 


The slave device responds to BDIN L negation by negating BRPLY L and 
removing read data from BDAL bus drivers. BRPLY L must be negated 100 ns 
(maximum) before removing read data. The bus master responds to the negated 
BRPLY L by negating BSYNC L. 


Conditions for the next BSYNC L assertion are as follows: 
¢ BSYNC L must remain negated for 200 ns (minimum). 


¢ BSYNC L must not become asserted within 300 ns of previous BRPLY L 
negation. 


Figure F—2 shows DATI bus cycle timing. 


Note 


When BSYNC L is continuously asserted, the bus master retains control 
of the bus and the previously addressed slave device remains selected. 
This is done for DATIO(B) bus cycles where DATO or DATOB follows 

a DATI without BSYNC L negation and a second device addressing 
operation. Also, a slow slave device can hold off data transfers to itself by 
keeping BRPLY L asserted, which causes the master to keep BSYNC L 
asserted. 
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Figure F-2 DATI Bus Cycle Timing 


150 NS 100NS  |_ __200 NS 
Minimum Minimum Maximum 
T SYNC ——_——— 200 NS Minimum 
ini Clock Dat: 
100 NS Minimum —+| Rear ene ey arise 200 NS 
8 pS Maximum Minimum 
T DIN 
300 NS Minimum 
R RPLY 
130 NS 
adie -_ 100 NS Minimum 
TBS7 (4) 
T WTBT (4) 
TIMING AT MASTER DEVICE 
R/T DAL 
25 NS = 100 NS Maximum 
Minimum 0 NS Minimum 
R SYNC 0NS 
Minimum 
75NS  j=e— k= 200 NS Maximum 150 NS 
Minimum Minimum 
R DIN 
oe 300 NS Minimum 
T RPLY 
—=—— 75 NS Minimum 
R BS7 
—}| es 25 NS Minimum 
RWTBT (4) (4) 
TIMING AT SLAVE DEVICE 
NOTES: 


1. Timing shown at master and slave device bus 
driver inputs and bus receiver outputs. 


2. Signal name prefixes are defined below: 


T=Bus Driver Input 
R=Bus Receiver Output 
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3. Bus driver output and bus receiver input 
signal names include a "B" prefix. 


4. Don’t care condition. 
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DATOB 

DATOB (Figure F-—3) is a write operation. Data is transferred in 32-bit words 
(DATO) or 8-bit bytes (DATOB) from the bus master to the slave device. The data 
transfer output can occur after the addressing part of a bus cycle when BWTBT L 
has been asserted by the bus master, or immediately following an input transfer 
part of a DATIOB bus cycle. 


Figure F-3 DATO or DATOB Bus Cycle 


Bus Master Slave 
(Processor or Device) (Memory or Device) 


Address device/memory 
e Assert BDAL <21:00> L with 
address and 
* Assert BBS7 L if address is 
in the I/O Page 
¢ Assert BWTBT L (write cycle) 
e Assert BSYNC L ree 


~ 2 Decode Address 
e Store "Device Selected" 
operation 


Output Data 
e Remove the address from 
BDAL <21:00> L and negate BBS7 L 
¢ Negate BWTBT L unless DATOB 
¢ Place data on BDAL <15:00> L 
e Assert BDOUT L ae 
— — ~ -m Take Data 
© Receive data from BDAL lines 
_ © Assert BRPLY L 


Terminate Output Transfer 
¢ Negate BDOUT L (and BWTBT L 
if in a DATOB bus cycle) 
« Remove data from BDAL <15:00>L _ 


~~  e Operation Completed 
Terminate Bus Cycle = - @ Negate BRPLY L 
e Negate BSYNC L 
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The data transfer part of a DATOB bus cycle comprises a data set-up and deskew 
time, and a data hold and deskew time. 


During the data set-up and deskew time, the bus master outputs the data on 
BDAL<15:00> L at least 100 ns after BSYNC L assertion. BWTBT L remains 
negated for the length of the bus cycle. If the transfer is a byte transfer, BWTBT 
L remains asserted. If it is the output of a DATIOB, BWTBT L becomes asserted 
and lasts the duration of the bus cycle. 
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During a byte transfer, BDAL<00> L selects the high or low byte. This occurs in 
the addressing part of the cycle. If asserted, the high byte (BDAL<15:08> L) is 
selected; otherwise, the low byte (BDAL<07:00> L) is selected. An asserted BDAL 
16 L at this time forces a parity error to be written into memory if the memory 
is a parity-type memory. BDAL 17 L is not used for write operations. The bus 
master asserts BDOUT L at least 100 ns after BDAL and BDWTBT L bus drivers 
are stable. The slave device responds by asserting BRPLY L within 10 ps to avoid 
bus timeout. This completes the data set-up and deskew time. 


During the data hold and deskew time, the bus master receives BRPLY L and 
negates BDOUT L, which must remain asserted for at least 150 ns from the 
receipt of BRPLY L before being negated by the bus master. BDAL<17:00> L bus 
drivers remain asserted for at least 100 ns after BDOUT L negation. The bus 
master then negates BDAL inputs. 


During this time, the slave device senses BDOUT L negation. The data is 
accepted and the slave device negates BRPLY L. The bus master responds by 
negating BSYNC L. However, the processor does not negate BSYNC L for at least 
175 ns after negating BDOUT L. This completes the DATOB bus cycle. Before 
the next cycle, BSYNC L must remain unasserted for at least 200 ns. Figure F—4 
shows DATOB bus cycle timing. 


F-12 @Q22-bus Specification 


Q22-bus Specification 
F.3 Data Transfer Bus Cycles 


Figure F-4 DATO or DATOB Bus Cycle Timing 
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T DOUT 


300 NS Minimum 
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TIMING AT MASTER DEVICE 


R/T DAL (4) 
R SYNC 
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R DIN 
25 NS 
T RPLY Minimum 
75 NS Minimum —— 
R BS7 
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|. 75 NS I 25 NS Minimum 
Minimum 
TIMING AT SLAVE DEVICE 
NOTES: 
1. Timing shown at requesting device bus driver 3. Bus driver output and bus receiver input 
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2. Signal name prefixes are defined below 4. Don’t care condition. 
T=Bus Driver Input 
R=Bus Receiver Output LJ-00179-Tlo 
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DATIOB 

The protocol for a DATIOB bus cycle (Figure F—5) is identical to the addressing 
and data transfer part of the DATI and DATOB bus cycles. After addressing the 
device, a DATI cycle is performed as explained in the DATI section; however, 
BSYNC L is not negated. BSYNC L remains active for an output word or byte 
transfer (DATOB). The bus master maintains at least 200 ns between BRPLY L 
negation during the DATI cycle and BDOUT L assertion. The cycle is terminated 
when the bus master negates BSYNC L, as described for DATOB. Figure F—6 
shows the DATIOB bus cycle timing. 
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Figure F-5 DATIO or DATIOB Bus Cycle 


Bus Master Slave 
(Processor or Device) (Memory or Device) 


Address device memory 
¢ Assert BDAL <21:00> L with 
address 


« Assert BBS7 L if the 
address is in the I/O page 
« Assert BSYNC L 


——~- Decode Address 
¢ Store "Device Selected" 
operation 
Request Data <-- 7 
«Remove the address from 
BDAL <21:00> L 
¢ Assert BDIN L Se 
-_=> Input Data 
e Place data on BDAL <15:00>L 
—- Assert BRPLY L 


Terminate Input Transfer << 
«Accept data and respond by 
terminating BDIN L 


Complete Input Transfer 
* Remove data 
* Negate BRPLY L 
en S 
Output Data 
¢ Place output data on BDAL <15:00> 
e Assert BWTBT L if an output 
byte transfer 
« Assert BDOUT L Se 


r 


~~~ Take Data 
*Receive data from BDAL lines 
_ _—- *Assert BRPLY L 
Terminate Output Transfer <«-— 
e Remove data from BDAL lines 
« Negate BDOUT L 


— + = Operation Completed 
_ #Negate BRPLY L 


Terminate Bus Cycle 
e Negate BSYNC L 
(and BWTBT L if N 
A DATIOB bus cycle) 
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Figure F-6 DATIO or DATIOB Bus Cycle Timing 
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NOTES: 
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T=Bus Driver Input 
R=Bus Receiver Output 
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3. Bus driver output and bus receiver input 


signal names include a "B" prefix. 
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F.4 Direct Memory Access 


The direct memory access (DMA) capability allows direct data transfer between 
I/O devices and memory. This is useful when using mass storage devices (for 
example, disks) that move large blocks of data to and from memory. A DMA 
device needs to be supplied with only the starting address in memory, the 
starting address in mass storage, the length of the transfer, and whether the 
operation is read or write. When this information is available, the DMA device 
can transfer data directly to or from memory. Since most DMA devices must 
perform data transfers in rapid succession or lose data, DMA devices are given 
the highest priority. 


DMA is accomplished after the processor (normally, bus master) has passed 
bus mastership to the highest priority DMA device that is requesting the bus. 
The processor arbitrates all requests and grants the bus to the DMA device 
electrically closest to it. A DMA device remains bus master until it relinquishes 
its mastership. The following control signals are used during bus arbitration: 


¢ BDMGIL DMA grant input 

¢ BDMGO L DMA grant output 

¢ BDMR L DMA request line 

¢ BSACK L bus grant acknowledge 


F.4.1_ DMA Protocol 
A DMA transaction can be divided into the following three phases: 


¢ Bus mastership acquisition phase 
¢ Data transfer phase 
¢ Bus mastership relinquishment phase 


During the bus mastership acquisition phase, a DMA device requests the bus by 
asserting BDMR L. The processor arbitrates the request and initiates the transfer 
of bus mastership by asserting BDMGO L. 


The maximum time between BDMR L assertion and BDMGO L assertion is DMA 
latency. This time is processor-dependent. BDMGO L/BDMGI L is one signal 
that is daisy-chained through each module in the backplane. 


BDMGO L/BDMGI L is driven out of the processor on the BDMGO L pin, enters 
each module on the BDMGI L pin, then exits on the BDMGO L pin. This signal 
passes through the modules in descending order of priority, until it is stopped by 
the requesting device. The requesting device blocks the output of BMDGO L and 
asserts BSACK L. If BDMR L is continuously asserted, the bus hangs. 


During the data transfer phase, the DMA device continues asserting BSACK L. 
The actual data transfer is performed as described earlier. 


The DMA device can assert BSYNC L for a data transfer 250 ns (minimum) after 
it received BDMGI L and its BSYNC L bus receiver is negated. 


During the bus mastership relinquishment phase, the DMA device gives up 
the bus by negating BSACK L. This occurs after completing (or aborting) the 
last data transfer cycle (BRPLY L negated). BSACK L can be negated up to a 
maximum of 300 ns before negating BSYNC L. 
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Note 


If multiple data transfers are performed during this phase, consideration 
must be given to the use of the bus for other system functions, such as 
memory refresh (if required). 


Figure F—7 shows the DMA protocol, and Figure F—8 shows DMA request/grant 
timing. 
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Figure F—7 DMA Protocol 


KDJ11-E Processor 
(Memory is Slave) 


Grant Bus Control 
e Near the end of the 

current bus cycle 
(BRPLY L is negated). 
Assert BDMGO L and 
inhibit new processor 
generated BSYNC L for 
the duration of the 
DMA operation. 


Terminate Grant 
Sequence 
«Negate BDMGO L and 
wait for DMA operation 
to be completed. 


Monitor the transaction to 
invalidate cache if 
cache hit. 


Resume Processor 
Operation 
Enable processor- 

generated BSYNC L 
(processor is bus 
master) or issue 
another grant if BDMR 
Lis asserted. 
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Bus Master 
(Controller) 


Request Bus 
e Assert BDMR L 


~ = Acknowledge Bus 


Mastership 

¢ Receive BDMG 

e Wait for negation of 
BSYNC L and BRPLY L 

e Assert BSACK L 

e Negate BDMR L 


= ~~ Execute a DMA Data 

Transfer 

e Address memory and 
transfer up to 4 words 
of data as described 
for DATI or DATO bus 
cycles. 

e Release the bus by 
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Figure F-8 DMA Request/Grant Timing 
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F.4.2 Block Mode DMA 


For increased throughput, block mode DMA can be implemented on a device for 
use with memories that support this type of transfer. In a block mode transaction, 
the starting memory address is asserted, followed by data for that address, and 
data for consecutive addresses. 


By eliminating the assertion of the address for each data word, the transfer rate 
is almost doubled. 


There are two types of block mode transfers, DATBI (input) and DATBO (output). 
¢ Section F.4.2.1 describes the DATBI bus cycle (Figure F—9). 
¢ Section F.4.2.2 describes the DATBO bus cycle (Figure F—10). 
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Figure F-9 DATBI Bus Cycle Timing 
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Figure F-10 DATBO Bus Cycle Timing 
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F.4.2.1_DATBI Bus Cycle 


Before a DATBI block mode transfer can occur, the DMA bus master device must 
request control of the bus. This occurs under conventional Q22—bus protocol. 


A block mode DATBI transfer is executed as follows: 


e Address device memory. The address is asserted by the bus master on 
TADDR<21:00> along with the negation of TWTBT. The bus master asserts 
TSYNC 150 ns (minimum) after gating the address onto the bus. 


¢ Decode the address. The appropriate memory device recognizes that it 
must respond to the address on the bus. 
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Request the data. The address is removed by the bus master from 
TADDR<21:00> 100 ns (minimum) after the assertion of TSYNC. The bus 
master asserts the first TDIN 100 ns (minimum) after asserting TSYNC. The 
bus master asserts TBS7 50 ns (maximum) after asserting TDIN for the first 
time. TBS7 remains asserted until 50 ns (maximum) after the assertion of 
TDIN for the last time. In each case, TBS7 can be asserted or negated as 
soon as the conditions for asserting TDIN are met. The assertion of TBS7 
indicates the bus master is requesting another read cycle after the current 
read cycle. 


Send the data. The bus slave asserts TRPLY between 0 ns (minimum) and 
8000 ns (maximum, to avoid a bus timeout) after receiving RDIN. The bus 
slave asserts TREF concurrent with TRPLY if, and only if, it is a block mode 
device that can support another RDIN after the current RDIN. The bus slave 
gates TDATA<15:00> onto the bus 0 ns (minimum) after receiving RDIN and 
125 ns (maximum) after the assertion of TRPLY. 


Note 


Block mode transfers must not cross 16-word boundaries. 


Terminate the input transfer. The bus master receives stable 
RDATA<15:00> from 200 ns (maximum) after receiving RRPLY until 20 

ns (minimum) after the negation of RDIN. (The 20 ns minimum represents 
total minimum receiver delays for RDIN at the slave and RDATA<15:00> at 
the master.) The bus master negates TDIN 200 ns (minimum) after receiving 
RRPLY. 


Operation completed. The bus slave negates TRPLY 0 ns (minimum) after 
receiving the negation of RDIN. If RBS7 and TREF are both asserted when 
TRPLY negates, the bus slave prepares for another DIN cycle. RBS7 is stable 
from 125 ns after RDIN is received until 150 ns after TRPLY negates. If 
TBS7 and RREF were both asserted when TDIN negated, the bus master 
asserts TDIN 150 ns (minimum) after receiving the negation of RRPLY and 
continues with the timing relationship in send data above. RREF is stable 
from 75 ns after RRPLY asserts until 20 ns (minimum) after TDIN negates. 
(The 0 ns minimum represents total minimum receiver delays for RDIN at 
the slave and RREF at the master.) 


Note 


The bus master must limit itself to no more than eight transfers, unless 
it monitors RDMR. If the bus master monitors RDMR, it may perform up 
to 16 transfers as long as RDMR is not asserted at the end of the seventh 
transfer. 


Terminate the bus cycle. If both RBS7 and TREF were not asserted when 
TRPLY negated, the bus slave removes TDATA<15:00> from the bus 0 ns 
(minimum) and 100 ns (maximum) after negating TRPLY. If TBS7 and RREF 
were not both asserted when TDIN negated, the bus master negates TSYNC 
250 ns (minimum) after receiving the last assertion of RRPLY and 0 ns 
(minimum) after the negation of that RRPLY. 
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Release the bus. The DMA bus master negates TSACK 0 ns after negation 
of the last RRPLY. The DMA bus master negates TSYNC 300 ns (maximum) 
after it negates TSACK. The DMA bus master must remove RDATA<15:00>, 
TBS7, and TWTBT from the bus 100 ns (maximum) after clearing TSYNC. 


At this point the block mode transfer is complete, and the bus arbitration logic 
in the CPU enables processor-generated TSYNC or issues another bus grant 
(TDMGO) if RDMR is asserted. 

F.4.2.2 DATBO Bus Cycle 
Before a block mode transfer can occur, the DMA bus master device must request 
control of the bus. This occurs under conventional Q22—bus protocol. 


A block mode DATBO transfer is executed as follows: 


Address device memory. The address is asserted by the bus master on 
TADDR<21:00> along with the aasertion of TWTBT. The bus master asserts 
TSYNC 150 ns (minimum) after gating the address onto the bus. 


Decode address. The appropriate memory device recognizes that it must 
respond to the address on the bus. 


Send data. The bus master gates TDATA<15:00> along with TWTBT 100 ns 
(minimum) after the assertion of TSYNC. TWTBT is negated. The bus master 
asserts the first TDOUT 100 ns (minimum) after gating TDATA<15:00>. 

Note 


During DATBO cycles, TBS7 is undefined. 


Receive data. The bus slave receives stable data on RDATA<15:00> from 25 
ns (minimum) before receiving RDOUT until 25 ns (minimum) after receiving 
the negation of RDOUT. The bus slave asserts TRPLY 0 ns (minimum) after 
receiving RDOUT. The bus slave asserts TREF concurrent with TRPLY if, and 
only if, it is a block mode device that can support another RDOUT after the 
current RDOUT. 


Note 


Block mode transfers must not cross 16-word boundaries. 


Terminate the output transfer. The bus master negates TDOUT 150 ns 
(minimum) after receiving RRPLY. 


Operation completed. The bus slave negates TRPLY 0 ns (minimum) after 
receiving the negation of RDOUT. If RREF were asserted when TDOUT 
negated and if the bus master wants to transfer another word, the bus master 
gates the new data on TDATA<15:00> 100 ns (minimum) after negating 
TDOUT. RREF is stable from 75 ns (maximum) after RRPLY asserts until 

20 ns (minimum) after RDOUT negates. (The 20 ns minimum represents 
minimum receiver delays for RDOUT at the slave and RREF at the master.) 
The bus master asserts TDOUT 100 ns (minimum) after gating new data on 
TDATA<15:00> and 150 ns (minimum) after receiving the negation of RRPLY. 
The cycle continues with the timing relationship in receive data above. 
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Note 


The bus master must limit itself to no more than eight transfers unless 
it monitors RDMR. If the bus master monitors RDMR, it may perform up 
to 16 transfers as long as RDMR is not asserted at the end of the seventh 
transfer. 


¢ Terminate the bus cycle. If RREF were not asserted when RRPLY negated 
or if the bus master has no additional data to transfer, the bus master 
removes data on TDATA<15:00> from the bus 100 ns (minimum) after 
negating TDOUT. If RREF were not asserted when TDOUT negated, the 
bus master negates TSYNC 275 ns (minimum) after receiving the last RRPLY 
and 0 ns (minimum) after the negation of the last RRPLY. 


¢ Release the bus. The DMA bus master negates TSACK 0 ns after negation 
of the last RRPLY. The DMA bus master negates TSYNC 300 ns (maximum) 
after it negates TSACK. The DMA bus master must remove TDATA, TBS7, 
and TWTBT from the bus 100 ns (maximum) after clearing TSYNC. 


At this point the block mode transfer is complete, and the bus arbitration logic 
in the CPU enables processor-generated TSYNC or issues another bus grant 
(TDMGO) if RDMR is asserted. 


F.4.3 DMA Guidelines 
The following is a list of DMA guidelines: 


¢ Systems with memory refresh over the bus must not include devices that 
perform more than one transfer per acquisition. 


¢ Bus masters that do not use block mode are limited to four DATI, four DATO, 
or two DATIO transfers per acquisition. 


¢ Block mode bus masters that do not monitor BDMR are limited to eight 
transfers per acquisition. 


e If BDMR is not asserted after the seventh transfer, block mode bus masters 
that do monitor BDMR may continue making transfers until the bus slave 
fails to assert BREF, or until they reach the total maximum of 16 transfers. 
Otherwise, they stop after eight transfers. 


F.5 Interrupts 


The interrupt capability of the Q22—-bus allows an I/O device to temporarily 
suspend (interrupt) current program execution and divert processor operation to 
service the requesting device. The processor inputs a vector from the device to 
start the service routine (handler). Like the device register address, hardware 
fixes the device vector at locations within a designated range below location 
001000. The vector indicates the first of a pair of addresses. The processor reads 
the contents of the first address, the starting address of the interrupt handler. 
The contents of the second address is a new processor status word (PS). 


The new PS can raise the interrupt priority level, thereby preventing lower-level 
interrupts from breaking into the current interrupt service routine. Control is 
returned to the interrupted program when the interrupt handler is ended. The 
original interrupted program’s address (PC) and its associated PS are stored on 
a stack. The original PC and PS are restored by a return from interrupt (RTI 
or RTT) instruction at the end of the handler. The use of the stack and the 
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Q22-bus interrupt scheme can allow interrupts to occur within interrupts (nested 
interrupts), depending on the PS. 


Interrupts can be caused by Q22-bus options or the KA680 CPU. Those interrupts 
that originate from within the processor are called traps. Traps are caused by 
programming errors, hardware errors, special instructions, and maintenance 
features. 


The following Q22-bus signals are used in interrupt transactions: 


Signal Definition 

BIRQ4 L Interrupt request priority level 4 
BIRQ5 L Interrupt request priority level 5 
BIRQ6 L Interrupt request priority level 6 
BIRQ7 L Interrupt request priority level 7 
BIAKI L Interrupt acknowledge input 
BIAKO L Interrupt acknowledge output 
BDAL<21:00> Data/address lines 

BDIN L Data input strobe 

BRPLY L Reply 


F.5.1 Device Priority 
The Q22-bus supports the following two methods of device priority: 


¢ Distributed arbitration — Priority levels are implemented on the hardware. 
When devices of equal priority level request an interrupt, priority is given to 
the device electrically closest to the processor. 


¢ Position-defined arbitration — Priority is determined solely by electrical 
position on the bus. The closer a device is to the processor, the higher its 
priority. 
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F.5.2 Interrupt Protocol 
Interrupt protocol on the Q22-bus has three phases: 


e Interrupt request 
¢ Interrupt acknowledge and priority arbitration 
¢ Interrupt vector transfer phase 


The interrupt request phase begins when a device meets its specific conditions for 
interrupt requests. For example, the device is ready, done, or an error occurred. 
The interrupt enable bit in a device status register must be set. The device then 
initiates the interrupt by asserting the interrupt request line(s). BIRQ4 L is 

the lowest hardware priority level and is asserted for all interrupt requests for 
compatibility with previous Q22-bus processors. The level at which a device is 
configured must also be asserted. A special case exists for level 7 devices that 
must also assert level 6. The following list gives the interrupt levels and the 
corresponding Q22-bus interrupt request lines. For an explanation, refer to 
Section F.5.3. 


Interrupt Level Lines Asserted by Device 

4 BIRQ4 L 

5 BIRQ4 L, BIRQ5 L 

6 BIRQ4 L, BIRQ6 L 

7 BIRQ4 L, BIRQ6 L, BIRQ7 L 


Figure F—11 shows the interrupt request/acknowledge sequence. 
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Figure F-11 Interrupt Request/Acknowledge Sequence 
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The interrupt request line remains asserted until the request is acknowledged. 


During the interrupt acknowledge and priority arbitration phase, the processor 
acknowledges interrupts under the following conditions: 


¢ The device interrupt priority is higher than the current PS<7:5>. 
¢ The processor has completed instruction execution and no additional bus 
cycles are pending. 


The processor acknowledges the interrupt request by asserting BDIN L, and 150 
ns (minimum) later asserting BIAKO L. The device electrically closest to the 
processor receives the acknowledge on its BIAKI L bus receiver. 


At this point, the two types of arbitration must be discussed separately. If the 
device that receives the acknowledge uses the 4-level interrupt scheme, it reacts 
as follows: 


F-28 @Q22-bus Specification 


Q22-bus Specification 
F.5 Interrupts 


e If not requesting an interrupt, the device asserts BIAKO L and the 
acknowledge propagates to the next device on the bus. 


¢ If the device is requesting an interrupt, it must check that no higher-level 
device is currently requesting an interrupt. This is done by monitoring 
higher-level request lines. The following table lists the lines that need to be 
monitored by devices at each priority level: 


Device Priority Level Line(s) Monitored 
4 BIRQ5, BIRQ6 

5 BIRQ6 

6 BIRQ7 

7 = 


In addition to asserting levels 7 and 4, level 7 devices must drive level 6. This 
is done to simplify the monitoring and arbitration by level 4 and 5 devices. In 
this protocol, level 4 and 5 devices need not monitor level 7 because level 7 
devices assert level 6. Level 4 and 5 devices become aware of a level 7 request 
because they monitor the level 6 request. This protocol has been optimized 
for level 4, 5, and 6 devices, since level 7 devices are very seldom necessary. 


¢ If no higher-level device is requesting an interrupt, the acknowledge is 
blocked by the device. (BIAKO L is not asserted.) Arbitration logic within the 
device uses the leading edge of BDIN L to clock a flip-flop that blocks BIAKO 
L. Arbitration is won and the interrupt vector transfer phase begins. 


¢ Ifa higher-level request line is active, the device disqualifies itself and asserts 
BIAKO L to propagate the acknowledge to the next device along the bus. 


Signal timing must be considered carefully when implementing four-level 
interrupts (Figure F—12). 
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Figure F-12 Interrupt Protocol Timing 
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If a single-level interrupt device receives the acknowledge, it reacts as follows: 


e If not requesting an interrupt, the device asserts BIAKO L and the 
acknowledge propagates to the next device on the bus. 


e Ifthe device was requesting an interrupt, the acknowledge is blocked using 
the leading edge of BDIN L, and arbitration is won. The interrupt vector 
transfer phase begins. 


The interrupt vector transfer phase is enabled by BDIN L and BIAKI L. The 
device responds by asserting BRPLY L and its BDAL<15:00> L bus driver inputs 
with the vector address bits. The BDAL bus driver inputs must be stable within 
125 ns (maximum) after BRPLY L is asserted. The processor then inputs the 
vector address and negates BDIN L and BIAKO L. The device then negates 
BRPLY L and 100 ns (maximum) later removes the vector address bits. The 
processor then enters the device’s service routine. 


Note 


Propagation delay from BIAKI L to BIAKO L must not be greater than 
500 ns per Q22-bus slot. The device must assert BRPLY L within 10 ps 
(maximum) after the processor asserts BIAKI L. 
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F.5.3 Q22-bus 4-level Interrupt Configurations 


If you have high-speed peripherals and desire better software performance, you 
can use the 4-level interrupt scheme. Both position-independent and position- 
dependent configurations can be used with the 4-level interrupt scheme. 


Figure F—13 shows the position-independent configuration. This allows peripheral 
devices that use the 4-level interrupt scheme to be placed in the backplane in 
any order. These devices must send out interrupt requests and monitor higher- 
level request lines as described. The level 4 request is always asserted from a 
requesting device regardless of priority. If two or more devices of equally high 
priority request an interrupt, the device physically closest to the processor wins 
arbitration. Devices that use the single-level interrupt scheme must be modified, 
or placed at the end of the bus, for arbitration to function properly. 


Figure F-13 Position-Independent Configuration 
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Figure F—14 shows the position-dependent configuration. This configuration is 
simpler to implement. A constraint is that peripheral devices must be inserted 
with the highest priority device located closest to the processor, and the remaining 
devices placed in the backplane in decreasing order of priority (with the lowest 
priority devices farthest from the processor). With this configuration, each device 
has to assert only its own level and level 4. Monitoring higher-level request lines 
is unnecessary. Arbitration is achieved through the physical positioning of each 
device on the bus. Single-level interrupt devices on level 4 should be positioned 
last on the bus. 
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Figure F-14 Position-Dependent Configuration 
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F.6 Control Functions 
The following Q22-bus signals provide control functions: 


Signal Definition 

BREF L Memory refresh (also block mode DMA) 
BHALT L Processor halt 

BINIT L Initialize 

BPOK H Power OK 

BDCOK H DC power OK 


F.6.1 Halt 
Assertion of BHALT L for at least 25 ns interrupts the processor, which stops 
program execution and forces the processor unconditionally into console I/O mode. 
F.6.2 Initialization 


Devices along the bus are initialized when BINIT L is asserted. The processor 
can assert BINIT L as a result of executing a reset instruction as part of a power- 
up or power-down sequence. BINIT L is asserted for approximately 10 ps when 
reset is executed. 


F.6.3 Power Status 


Power status protocol is controlled by two signals, BPOK H and BDCOK H. These 
signals are driven by an external device (usually the power supply). 


F.7 Q22-bus Electrical Characteristics 
Section F.7.1 lists the input and output logic levels for Q22—bus signals. 
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F.7.1 Signal Level Specifications 


The signal level specifications for the Q22—bus are as follows: 


Input Logic Level 


TTL logical low 3 
TTL logical high 0.8 Vde (maximum) 


2.0 Vdc (minimum) 


Output Logic Level 
TTL logical low an 
TTL logical high 2.4 Vde (minimum) 


0.4 Vdc (maximum) 


F.7.2 Load Definition 


AC loads make up the maximum capacitance allowed per signal line to ground. A 
unit load is defined as 9.35 pF of capacitance. DC loads are defined as maximum 
current allowed with a signal line driver asserted or unasserted. A unit load is 
defined as 210 pA in the unasserted state. 


F.7.3 120-Ohm Q22—bus 


The electrical conductors interconnecting the bus device slots are treated as 
transmission lines. A uniform transmission line, terminated in its characteristic 
impedance, propagates an electrical signal without reflections. Since bus drivers, 
receivers, and wiring connected to the bus have finite resistance and nonzero 
reactance, the transmission line impedance is not uniform, and introduces 
distortions into pulses propagated along it. Passive components of the Q22—bus 
(such as wiring, cabling, and etched signal conductors) are designed to have a 
nominal characteristic impedance of 120 ohms. 


The maximum length of interconnecting cable, excluding wiring within the 
backplane, is limited to 4.88 m (16 ft). 


F.7.4 Bus Drivers 


Devices driving the 120-ohm Q22-bus must have open collector outputs and meet 
the following specifications: 


DC Specifications 
¢ Output low voltage when sinking 70 mA of current is 0.7 V (maximum). 


¢ Output high leakage current when connected to 3.8 Vdc is 25 pA (even if no 
power is applied, except for BDCOK H and BPOK H). 


¢ These conditions must be met at worst-case supply temperature, and input 
signal levels. 


AC Specifications 
¢ Bus driver output pin capacitance load should not exceed 10 pF. 
¢ Propagation delay should not exceed 35 ns. 


¢ Skew (difference in propagation time between slowest and fastest gate) should 
not exceed 25 ns. 


¢ Transition time (from 10% to 90% for positive transition—rise time, from 90% 
to 10% for negative transition—fall time) must be no faster than 10 ns. 
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F.7.5 Bus Receivers 


Devices that receive signals from the 120-ohm Q22-bus must meet the following 
requirements: 


DC Specifications 
¢ Input low voltage is 1.3 V (maximum). 
¢ Input high voltage is 1.7 V (minimum). 


¢ Maximum input current when connected to 3.8 Vdc is 80 pA (even if no power 
is applied). 


These specifications must be met at worst-case supply voltage, temperature, and 
output signal conditions. 


AC Specifications 
¢ Bus receiver input pin capacitance load should not exceed 10 pF. 
¢ Propagation delay should not exceed 35 ns. 


e Skew (difference in propagation time between slowest and fastest gate) should 
not exceed 25 ns. 


F.7.6 Bus Termination 


The 120-ohm Q22-bus must be terminated at each end by an appropriate 
terminator, as shown in Figure F—15. This is to be done as a voltage divider 
with its Thevenin equivalent equal to 120 ohms and 3.4 V (nominal). This type 
of termination is provided by an REV11-A refresh/boot/terminator, BDV11-AA, 
KPV11-B, TEV11, or by certain backplanes and expansion cards. 


Figure F-15 Bus Line Terminations 
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Each of the several Q22-bus lines (all signals whose mnemonics start with the 
letter B) must see an equivalent network with the following characteristics at 
each end of the bus: 
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Bus Termination Characteristic Value 

Input impedance 120 ohms +5%, —15% 

(with respect to ground) 

Open circuit voltage 3.4 Vde +5% 

Capacitance load Not to exceed 30 pF 
Note 


The resistive termination can be provided by the combination of two 
modules. (The processor module supplies 220 ohms to ground. This, 
in parallel with another 220-ohm card, provides 120 ohms.) Both 
terminators must reside physically within the same backplane. 


F.7.7 Bus Interconnecting Wiring 


The following sections give specific information about bus interconnecting wiring. 


F.7.7.1_| Backplane Wiring 


The wiring that connects all device interface slots on the Q22—bus must meet the 
following specifications: 


¢ The conductors must be arranged so that each line exhibits a characteristic 
impedance of 120 ohms (measured with respect to the bus common return). 


¢ Cross talk between any two lines must be no greater than 5 percent. Note 
that worst-case cross talk is manifested by simultaneously driving all but one 
signal line and measuring the effect on the undriven line. 


¢ DC resistance of the signal path, as measured between the near-end 
terminator and the far-end terminator module (including all intervening 
connectors, cables, backplane wiring, and connector-module etch) must not 
exceed 20 ohms. 


¢ DC resistance of the common return path, as measured between the near- 
end terminator and the far-end terminator module (including all intervening 
connectors, cables, backplane wiring and connector-module etch) must not 
exceed an equivalent of 2 ohms per signal path. Thus, the composite signal 
return path dc resistance must not exceed 2 ohms divided by 40 bus lines, 
or 50 milliohms. Note that although this common return path is nominally 
at ground potential, the conductance must be part of the bus wiring. The 
specified low impedance return path must be provided by the bus wiring as 
distinguished from the common system or power ground path. 


F.7.7.2 Intrabackplane Bus Wiring 


The wiring that connects the bus connector slots within one contiguous backplane 
is part of the overall bus transmission line. Owing to implementation constraints, 
the nominal characteristic impedance of 120 ohms may not be achievable. 
Distributed wiring capacitance in excess of the amount required to achieve the 
nominal 120-ohm impedance may not exceed 60 pF per signal line per backplane. 
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F.7.7.3. Power and Ground 


Each bus interface slot has connector pins assigned for the following dc voltages. 
The maximum allowable current per pin is 1.5 A. +5 Vdc must be regulated to 5 
percent, with a maximum ripple of 100 mV pp. +12 Vdc must be regulated to 3 

percent, with a maximum ripple of 200 mV pp. 


¢ +5 Vdc — Three pins (4.5 A maximum per bus device slot) 
¢ +12 Vde — Two pins (3.0 A maximum per bus device slot) 


¢ Ground — Eight pins (shared by power return and signal return) 


Note 


Power is not bused between backplanes on any interconnecting bus cables. 


F.8 System Configurations 
Q22-bus systems can be divided into two types: 
¢ Systems containing one backplane 
¢ Systems containing multiple backplanes 


Before configuring any system, three characteristics for each module in the 
system must be identified. 


¢ Power consumption — +5 Vdc and +12 Vdc are the current requirements. 


¢ AC bus loading — The amount of capacitance a module presents to a bus 
signal line. AC loading is expressed in terms of ac loads, where one ac load 
equals 9.35 pF of capacitance. 


¢ DC bus loading—The amount of dc leakage current a module presents to a 
bus signal when the line is high (undriven). DC loading is expressed in terms 
of de loads, where one dc load equals 210 pA (nominal). 


Power consumption, ac loading, and dc loading specifications for each module are 
included in the Microcomputer Interfaces Handbook. 


Note 


The ac and dc loads and the power consumption of the processor module, 
terminator module, and backplane must be included in determining the 
total loading of a backplane. 


Rules for configuring single backplane systems are as follows: 


¢ When using a processor with 220-ohm termination, the bus can accommodate 
modules that have up to 20 ac loads before additional termination is required 
(Figure F-16). If more than 20 ac loads are included, the other end of the bus 
must be terminated with 120 ohms. Then, up to 35 ac loads may be present. 


¢ With 120-ohm processor termination, up to 35 ac loads can be used without 
additional termination. If 120-ohm bus termination is added, up to 45 ac 
loads can be configured in the backplane. 


¢ The bus can accommodate modules up to 20 dc loads (total). 


F-36 @Q22-bus Specification 


Q22-bus Specification 
F.8 System Configurations 


¢ The bus signal lines on the backplane can be up to 35.6 cm (14 in) long. 


Figure F-16 Single Backplane Configuration 
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Rules for configuring multiple backplane systems are as follows: 
¢ Figure F—17 shows that up to three backplanes can make up the system. 
¢ The signal lines on each backplane can be up to 25.4 cm (10 in) long. 


¢ Each backplane can accommodate modules that have up to 22 ac loads. 
Unused ac loads from one backplane may not be added to another backplane 
if the second backplane loading exceeds 22 ac loads. It is desirable to load 
backplanes equally, or with the highest ac loads in the first and second 
backplanes. 


¢ DC loading of all modules in all backplanes cannot exceed 20 loads. 


¢ Both ends of the bus must be terminated with 120 ohms. This means 
the first and last backplanes must have an impedance of 120 ohms. To 
achieve this, each backplane can be lumped together as a single point. The 
resistive termination can be provided by a combination of two modules in 
the backplane — the processor providing 220 ohms to ground in parallel with 
an expansion paddle card providing 250 ohms to give the needed 120-ohm 
termination. 


Alternately, a processor with 120-ohm termination would need no additional 
termination on the paddle card to attain 120 ohms in the first box. The 
120-ohm termination in the last box can be provided in two ways: the 
termination resistors may reside on either the expansion paddle card, or 
on a bus termination card (such as the BDV11). 


¢ The cable(s) connecting the first two backplanes is 61 cm (2 ft) or more in 
length. 
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Figure F-17 Multiple Backplane Configuration 
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¢ The cable(s) connecting the second backplane to the third backplane is 122 
cm (4 ft) longer or shorter than the cable(s) connecting the first and second 
backplanes. 


¢ The combined length of both cables cannot exceed 4.88 m (16 ft). 


¢ The cables used must have a characteristic impedance of 120 ohms. 


F.8.1 Power Supply Loading 


Total power requirements for each backplane can be determined by obtaining 
the total power requirements for each module in the backplane. Obtain separate 
totals for +5 V and +12 V power. Power requirements for each module are 
specified in the Microcomputer Interfaces Handbook. 


When distributing power in multiple backplane systems, do not attempt to 
distribute power through the Q22-bus cables. Provide separate, appropriate 
power wiring from each power supply to each backplane. Each power supply 
should be capable of asserting BPOK H and BDCOK H signals according to 
bus protocol; this is required if automatic power-fail/restart programs are 
implemented, or if specific peripherals require an orderly power-down halt 
sequence. The proper use of BPOK H and BDCOK H signals is strongly 
recommended. 


F.9 Module Contact Finger Identification 


All of Digital’s plug-in modules use the same contact finger (pin) identification 
system. A typical pin is shown in Figure F-18. 


Figure F-18 Typical Pin Identification System 
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The Q22-bus is based on the use of quad-height modules that plug into a 2-slot 
bus connector. Each slot contains 36 lines (18 lines on both the component side 
and the solder side of the circuit board). 


Slots, row A, and row B include a numeric identifier for the side of the module. 
The component side is designated side 1 and the solder side is designated side 2, 
as shown in Figure F-19. 


Q22-bus Specification F-39 


Q22-bus Specification 
F.9 Module Contact Finger Identification 


Figure F-19 Quad-Height Module Contact Finger Identification 
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Letters ranging from A through V (excluding G, I, O, and Q) identify a particular 
pin on a side of a slot. Table F—7 lists and identifies the bus pins of the quad- 
height module. A bus pin identifier ending with a 1 is found on the component 
side of the board, while a bus pin identifier ending with a 2 is found on the solder 
side of the board. 


The positioning notch between the two rows of pins mates with a protrusion on 
the connector block for correct module positioning. 


Figure F—20 represents the dimensions for a typical Q22—bus module. 
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Figure F-20 Typical Q22—bus Module Dimensions 
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Table F—-7 Bus Pin Identifiers 

Bus Pin Signal Definition 

AAI BIRQ5 L Interrupt request priority level 5. 

ABI BIRQ6 L Interrupt request priority level 6. 

AC1 BDAL16 L Extended address bit during addressing protocol; 
memory error data line during data transfer 
protocol. 

AD1 BDAL17 L Extended address bit during addressing protocol; 
memory error logic enable during data transfer 
protocol. 

AE1 SSPARE1 Special spare — Not assigned or bused in Digital’s 


(alternate +5 B) 


cable or backplane assemblies. Available for user 
connection. Optionally, this pin can be used for 
+5 V battery (+5 B) back-up power to keep critical 
circuits alive during power failures. A jumper is 
required on Q22-bus options to open (disconnect) 
the +5 B circuit in systems that use this line as 
SSPARE1. 


(continued on next page) 
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Table F—7 (Cont.) Bus Pin Identifiers 


Bus Pin 


Signal 


Definition 


AF1 


AH1 


AJ1 
AK1 


AL1 


AP1 
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SSPARE2 


SSPARE3 
SRUN 


GND 
MSPAREA 


MSPAREB 


GND 
BDMR L 


BHALT L 


Special spare — Not assigned or bused in Digital’s 
cable or backplane assemblies. Available for user 
interconnection. In the highest priority device 
slot, the processor can use this pin for a signal to 
indicate its run state. 


Special spare — Not assigned or bused 
simultaneously in Digital’s cable or backplane 
assemblies; available for user interconnection. An 
alternate SRUN signal can be connected in the 
highest priority set. 


Ground — System signal ground and dc return. 


Maintenance spare — Normally connected 
together on the backplane at each option location 
(not a bused connection). 


Maintenance spare — Normally connected 
together on the backplane at each option location 
(not a bused connection). 


Ground — System signal ground and dc return. 


DMA request — A device asserts this signal to 
request bus mastership. The processor arbitrates 
bus mastership between itself and all DMA 
devices on the bus. If the processor is not bus 
master (it has completed a bus cycle and BSYNC 
L is not being asserted by the processor), it 
grants bus mastership to the requesting device 
by asserting BDMGO L. The device responds by 
negating BDMR L and asserting BSACK L. 


Processor halt — When BHALT L is asserted 

for at least 25 us, the processor services the halt 
interrupt and responds by halting normal program 
execution. External interrupts are ignored but 
memory refresh interrupts in Q22—bus operations 
are enabled if W4 on the M7264 and M7264-YA 
processor modules is removed and DMA request 
/grant sequences are enabled. The processor 
executes the ODT microcode, and the console 
device operation is invoked. 
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Table F—7 (Cont.) Bus Pin Identifiers 


Bus Pin 


Signal 


Definition 


ARI 


AS1 


AT1 
AU1 


AV1 


BAI 


BB1 


BC1 


BREF L 


+12 Bor+5B 


GND 
PSPARE 1 


+5 B 


BDCOK H 


BPOK H 


SSPARE4 
BDAL18 L 
(22-bit only) 


Memory refresh — Asserted by a DMA device. 
This signal forces all dynamic MOS memory units 
requiring bus refresh signals to be activated for 
each BSYNC L/BDIN L bus transaction. It is also 
used as a control signal for block mode DMA. 


__ Caution 


The user must avoid 
multiple DMA data 
transfers (burst or hot 
mode) that could delay 
refresh operation if 
using DMA refresh. 
Complete refresh 
cycles must occur 
once every 1.6 ms if 
required. 


+12 Vdc or +5 V battery back-up power to keep 
critical circuits alive during power failures. 

This signal is not bused to BS1 in all Digital 
backplanes. A jumper is required on all Q22—bus 
options to open (disconnect) the back-up circuit 
from the bus in systems that use this line at the 
alternate voltage. 


Ground — System signal ground and dc return. 


Spare — Not assigned. Customer usage not 
recommended. Prevents damage when modules 
are inserted upside down. 


+5 V battery power — Secondary +5 V power 
connection. Battery power can be used with 
certain devices. 


DC power OK — A power supply generated signal 
that is asserted when the available dc voltage is 
sufficient to sustain reliable system operation. 


Power OK — Asserted by the power supply 70 
ms after BDCOK is negated when ac power 
drops below the value required to sustain power 
(approximately 75% of nominal). When negated 
during processor operation, a power-fail trap 
sequence is initiated. 


Special spare in the Q22—bus — Not assigned. 
Bused in 22-bit cable and backplane assemblies. 
Available for user interconnection. 


(continued on next page) 
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Table F—7 (Cont.) Bus Pin Identifiers 


Bus Pin Signal Definition 
BD1 SSPARE5 
BDAL19 L 
(22-bit only) Caution 
These pins 
may be used by 
manufacturing as 
test points in some 
options. 

BE1 SSPARE6 In the Q22-bus, these bused address lines are 

BDAL20 L address lines <21:18>. Currently not used during 
data time. 

BF1 SSPARE7 In the Q22-bus, these bused address lines are 

BDAL21 L address lines <21:18>. Currently not used during 
data time. 

BH1 SSPARE8 Special spare — Not assigned or bused in Digital’s 
cable and backplane assemblies. Available for 
user interconnection. 

BJ1 GND Ground — System signal ground and dc return. 

BK1 MSPAREB Maintenance spare — Normally connected 

BLI1 MSPAREB together on the backplane at each option location 
(not a bused connection). 

BM1 GND Ground — System signal ground and dc return. 

BN1 BSACK L This signal is asserted by a DMA device in 
response to the processor’s BDMGO L signal, 
indicating that the DMA device is bus master. 

BP1 BIRQ7 L Interrupt request priority level 7. 

BR1 BEVNT L External event interrupt request — When 
asserted, the processor responds by entering a 
service routine through vector address 1008. A 
typical use of this signal is as a line time clock 
(LTC) interrupt. 

BS1 +12 B +12 Vdc battery back-up power (not bused to AS1 
in all Digital backplanes). 

BT1 GND Ground — System signal ground and dc return. 

BU1 PSPARE2 Power spare 2 — Not assigned a function and not 
recommended for use. If a module is using 
—12 V (on pin AB2) and, if the module is 
accidentally inserted upside down in the 
backplane, —12 Vdc appears on pin BU1. 

BV1 +5 +5 V power — Normal +5 Vdc system power. 

AA2 +5 +5 V power — Normal +5 Vdc system power. 
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Table F—7 (Cont.) Bus Pin Identifiers 


Bus Pin Signal Definition 


AB2 -12 —12 V power — —12 Vdc power for (optional) 
devices requiring this voltage. Each Q22—bus 
module that requires negative voltages contains 
an inverter circuit that generates the required 
voltage(s). Therefore, —12 V power is not required 
with Digital’s options. 


AC2 GND Ground — System signal ground and dc return. 
AD2 +12 +12 V power — +12 Vdc system power. 
AE2 BDOUT L Data output — When asserted, BDOUT implies 


that valid data is available on BDAL<0:15> L 
and that an output transfer, with respect to the 
bus master device, is taking place. BDOUT L is 
deskewed with respect to data on the bus. The 
slave device responding to the BDOUT L signal 
must assert BRPLY L to complete the transfer. 


AF2 BRPLY L Reply — BRPLY L is asserted in response 
to BDIN L or BDOUT L and during IAK 
transactions. It is generated by a slave device 
to indicate that it has placed its data on the 
BDAL bus or that it has accepted output data 
from the bus. 


AH2 BDIN L Data input — BDIN L is used for two types of bus 
operations. 


¢ When asserted during BSYNC L time, BDIN 
L implies an input transfer with respect 
to the current bus master, and requires a 
response (BRPLY L). BDIN L is asserted 
when the master device is ready to accept 
data from the slave device. 


¢ When asserted without BSYNC L, it indicates 
that an interrupt operation is occurring. The 
master device must deskew input data from 
BRPLY L. 


AJ2 BSYNC L Synchronize — BSYNC L is asserted by the bus 
master device to indicate that it has placed an 
address on BDAL<0:17> L. The transfer is in 
process until BSYNC L is negated. 


AK2 BWTBT L Write/byte — BWTBT L is used in two ways to 
control a bus cycle. 


e It is asserted at the leading edge of BSYNC L 
to indicate that an output sequence (DATO or 
DATOB), rather than an input sequence, is to 
follow. 


e It is asserted during BDOUT L, in a DATOB 
bus cycle, for byte addressing. 


(continued on next page) 
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Table F—7 (Cont.) Bus Pin Identifiers 


Bus Pin 


Signal 


Definition 


AL2 


AM2 
AN2 


AS2 
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BIRQ4 L 


BIAKI L 
BIAKO L 


BBS7 L 


BDMGI L 
BDMGO L 


Interrupt request priority level 4 — A level 4 
device asserts this signal when its interrupt 
enable and interrupt request flip-flops are set. If 
the PS word bit 7 is 0, the processor responds by 
acknowledging the request by asserting BDIN L 
and BIAKO L. 


Interrupt acknowledge — In accordance with 
interrupt protocol, the processor asserts BIAKO L 
to acknowledge receipt of an interrupt. The bus 
transmits this to BIAKI L of the device electrically 
closest to the processor. This device accepts the 
interrupt acknowledge under two conditions. 


¢ The device requested the bus by asserting 
BIRQn L (where n= 4, 5, 6 or 7). 


¢ The device has the highest priority interrupt 
request on the bus at that time. 


If these conditions are not met, the device asserts 
BIAKO L to the next device on the bus. This 
process continues in a daisy-chain fashion until 
the device with the highest interrupt priority 
receives the interrupt acknowledge signal. 


Bank 7 select — The bus master asserts this 
signal to reference the I/O page (including that 
part of the page reserved for nonexistent memory). 
The address in BDAL<0:12> L when BBS’ L is 
asserted is the address within the I/O page. 


Direct memory access grant — The bus arbitrator 
asserts this signal to grant bus mastership to a 
requesting device, according to bus mastership 
protocol. The signal is passed in a daisy chain 
from the arbitrator (as BDMGO L) through the 
bus to BDMGI L of the next priority device (the 
device electrically closest on the bus). 


This device accepts the grant only if it requested 
to be the bus master (by a BDMR L). If not, the 
device passes the grant (asserts BDMGO L) to the 
next device on the bus. This process continues 
until the requesting device acknowledged the 
grant. 


_ Caution 


DMA device transfers 
must not interfere 
with the memory 
refresh cycle. 
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Bus Pin Signal Definition 


AT2 BINIT L Initialize — This signal is used for system reset. 
All devices on the bus are to return to a known, 
initial state; that is, registers are reset to zero, 
and logic is reset to state 0. Exceptions should 
be completely documented in programming and 
engineering specifications for the device. 


AU2 BDALO L Data/address lines — These two lines are part of 
AV2 BDAL1 L the 16-line data/address bus over which address 
and data information are communicated. Address 
information is first placed on the bus by the 
bus master device. The same device then either 
receives input data from, or outputs data to, the 
addressed slave device or memory over the same 


bus lines. 
BA2 +5 +5 V power — Normal +5 Vdc system power. 
BB2 -12 —12 V power (voltage not supplied) — —12 Vdc 
power for (optional) devices requiring this voltage. 
BC2 GND Ground — System signal ground and dc return. 
BD2 +12 +12 V power — +12 V system power. 
BE2 BDAL2 L Data/address lines — These 14 lines are part of 
BF2 BDAL3 L the 16-line data/address bus. 
BH2 BDAL4 L 
BJ2 BDAL5 L 
BK2 BDAL6 L 
BL2 BDAL7 L 
BM2 BDAL8 L 
BN2 BDAL9Y L 
BP2 BDAL10 L 
BR2 BDAL11 L 
BS2 BDAL12 L 
BT2 BDAL13 L 
BU2 BDAL14 L 
BV2 BDAL15 L 
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This appendix describes the physical, electrical, and environmental characteristics 
of the KA680 CPU module. 


G.1 Dimensions 
The KA680 and MS690 are quad-height modules with the following dimensions: 


Height - 10.457 +.015/ -.020 inches 
Length - 8.430 +.010/ -.010 inches 
Width - .375 inches maximum (nonconductive) 


.343 inches maximum (conductive) 


Note 


Width, as defined for Digital modules, is the height of components above 
the surface of the module. 


G.2 KA680 Connectors 


The KA680 has two connector interfaces: the 270-pin backplane connector and the 100-pin 
console module connector. 


G.2.1 KA680 Backplane Connector 
The pinout of the KA680’s 270-pin backplane connector is as follows: 


Pin Signal Name 

001 SH2_DATA <7> L 
002 GROUND 

003 SH2_DATA <6> L 
004 SH2_DATA <5> L 
005 + 5V 

006 SH2_DATA <4> L 
007 SH2_DATA <3> L 
008 VM12VOLTSL1 
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G.2 KA680 Connectors 
Pin Signal Name 
009 SH2_DATA <2> L 
010 SH2_DATA <1>L 
011 GROUND 
012 SH2_DATA <0> 
013 SH2_ DP L 
014 V12VOLTS1 
015 SH2_BSY L 
016 SH2_ACK L 
018 SH2_RST L 
019 SH2_ SEL L 
021 SH2 CD L 
022 SH2_REQ L 
023 GROUND 
024 SH2 IO L 
026 + 5V 
027 BIRQ L<5> 
028 BIRQ L<6> 
029 VD3A 
030 BDAL L<16> 
031 BDAL L<17> 
033 BDOUT L 
034 SRUN L 
035 GROUND 
036 BRPLY L 
037 BDIN L 
039 BSYNC L 
040 BWTBT L 
042 BIRQ L<4> 
045 BDMR L 
046 BIAKO L 
047 GROUND 
048 BHALT L 
049 BBS7 L 
050 + 5V 
051 BREF L 
054 BDMGO L 
055 BINIT L 
056 VM12VOLTSL2 
057 BDAL L<0> 
058 BDAL L<1> 
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G.2 KA680 Connectors 
Pin Signal Name 
059 GROUND 
060 BDCOK 
061 BPOK 
062 V12VOLTS2 
063 BDAL L<18> 
064 BDAL L<19> 
066 BDAL L<20> 
067 BDAL L<2> 
069 BDAL L<21> 
070 BDAL L<3> 
O71 GROUND 
072 BDAL L<4> 
073 BDAL L<5> 
074 + 5V 
075 BDAL L<6> 
076 BDAL L<7> 
077 VD3B 
078 BDAL L<8> 
079 BSACK L 
081 BDAL L<9> 
082 BIRQ L<7> 
083 GROUND 
084 BDAL L<10> 
085 BEVENT L 
087 BDAL L<11> 
088 BDAL L<12> 
090 BDAL L<13> 
091 BDAL L<14> 
093 BDAL L<15> 
094 TRST 
095 GROUND 
096 MD<0> 
097 MD<1> 
098 + 5V 
099 MD<2> 
100 MD<3> 
101 V12VOLTS3 
102 MD<4> 
103 MD<5> 
105 MD<6> 
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G.2 KA680 Connectors 
Pin Signal Name 
106 MD<7> 
107 GROUND 
108 MD<8> 
109 MD<9> 
111 MD<10> 
112 MD<11> 
114 MD<12> 
115 MD<13> 
117 MD<14> 
118 MD<15> 
119 GROUND 
120 MD<16> 
121 MD<17> 
122 + 5V 
123 MD<18> 
124 MD<19> 
125 VD3C 
126 MD<20> 
127 MD<21> 
129 MD<22> 
130 MD<23> 
131 GROUND 
132 MD<24> 
133 MD<25> 
135 MD<26> 
136 MD<27> 
138 MD<28> 
139 MD<29> 
141 MD<30> 
142 MD<31> 
143 GROUND 
144 MD<64> 
145 MD<65> 
146 + 5V 
147 MD<66> 
148 MD<67> 
149 V12VOLTS4 
150 MD<68> 
151 MD<69> 
152 GROUND 
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G.2 KA680 Connectors 
Pin Signal Name 
153 MD<70> 
154 NO CONNECTION 
155 GROUND 
156 CASA_H 
157 CASB_H 
160 SE_H 
161 GROUND 
162 WE_H 
163 RAS_TIME_H 
165 BANK_SEL<0> 
167 GROUND 
168 BANK_SEL<1> 
169 BANK_SEL<2> 
170 + 5V 
171 BANK_SEL<3> 
172 MODE_SEL<0> 
173 VD3D 
176 GROUND 
177 MODE_SEL<1> 
178 MA<0> 
179 GROUND 
180 MA<1> 
181 MA<2> 
182 + 5V 
183 NMCJTDI 
184 NMCJTDO 
186 MA<3> 
187 MA<4> 
188 GROUND 
189 MA<5> 
190 MA<6> 
191 GROUND 
192 NMCJTMS 
193 NMCJTCK 
195 MA<7> 
197 GROUND 
198 MA<8> 
199 NCAJTDI 
201 NCAJTDO 
202 NCAJTMS 
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G.2 KA680 Connectors 
Pin Signal Name 
203 GROUND 
204 MA<9> 
205 NCAJTCK 
206 + 5V 
207 MA<10> 
209 VD3E 
211 MD<32> 
213 MD<33> 
214 MD<34> 
215 GROUND 
216 MD<35> 
217 MD<36> 
219 MD<37> 
220 MD<38> 
221 GROUND 
222 MD<39> 
223 MD<40> 
225 MD<41> 
226 MD<42> 
227 GROUND 
228 MD<43> 
229 MD<44> 
230 + 5V 
231 MD<45> 
232 MD<46> 
233 GROUND 
234 MD<47> 
235 MD<48> 
237 MD<49> 
238 MD<50> 
239 GROUND 
240 MD<51> 
243 MD<52> 
244 MD<53> 
245 GROUND 
246 MD<54> 
247 MD<55> 
249 MD<56> 
250 MD<57> 
251 GROUND 
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G.2 KA680 Connectors 
Pin Signal Name 
252 MD<58> 
253 MD<59> 
254 + 5V 
255 MD<60> 
256 MD<61> 
257 VD3F 
258 MD<62> 
259 MD<63> 
260 NO CONNECTION 
261 MD<71> 
263 GROUND 
264 NVAX_JTDI 
265 NVAX_JTDO 
267 NVAX_JTMS 
268 NVAX_JTCK 
270 TSTPHIIN 


G.2.2 KA680 Console Connector (J2) 


The 100-pin console connector provides the connection between the KA680 and 
the H3604 console module. Table G—1 lists the J2 pinouts. 


Table G-1 KA680 Console Connector (J2) Pinout 


Pin Signal Name Usage Meaning 

1 GND Ground Signal Ground. 

2-3 SH1_DATA<0> L DSSI DSSI #1 Data Bus Bit 0. 
4 GND Ground Signal Ground. 

5-6 SH1_DATA<1> L DSSI DSSI #1 Data Bus Bit 1. 
7 GND Ground Signal Ground. 

8-9 SH1_DATA<2> L DSSI DSSI #1 Data Bus Bit 2. 
10 GND Ground Signal Ground. 

11-12 SH1_DATA<3> L DSSI DSSI #1 Data Bus Bit 3. 
13 GND Ground Signal Ground. 

14-15 SH1_DATA<4> L DSSI DSSI #1 Data Bus Bit 4. 
16 GND Ground Signal Ground. 

17-18 SH1_DATA<5> L DSSI DSSI #1 Data Bus Bit 5. 
19 GND Ground Signal Ground. 

20 - 21 SH1_DATA<6> L DSSI DSSI #1 Data Bus Bit 6. 
22 GND Ground Signal Ground. 

23 - 24 SH1_DATA<7> L DSSI DSSI #1 Data Bus Bit 7. 
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G.2 KA680 Connectors 


Table G—1 (Cont.) KA680 Console Connector (J2) Pinout 


Pin Signal Name Usage Meaning 

25 GND Ground Signal Ground. 

26 - 27 SH1_DP L DSSI DSSI #1 Data Bus Parity 
Line. 

28 GND Ground Signal Ground. 

29 - 30 SH1_ACK L DSSI This signal is driven by 
an initiator to indicate 
an acknowledgment for a 
REQ/ACK data transfer 
handshake. 

31 GND Ground Signal Ground. 

32 - 33 SH1_RST L DSSI DSSI Pin RESET. 

34 GND Ground Signal Ground. 

35 - 36 SH1_SEL L DSSI DSSI Pin SELECT A 
signal. Used by the 
initiator to select a target. 

37 GND Ground Signal Ground. 

38 - 39 SH1_C/D L DSSI Pin Command/Data. A 
signal driven by a target 
that indicates whether 
control or data information 
is on the data bus. 
Asserted (low) indicates 
control. 

40 GND Ground Signal Ground. 

41 - 42 SH1_REQ L DSSI REQUEST. A signal driven 
by a target to indicate a 
request for a REQ/ACK 
data transfer handshake. 

43 GND Ground Signal Ground. 

44-45 SH1I/O L DSSI Input/output. A signal 
driven by a target that 
controls the direction of 
data movement on the data 
bus with respect to the 
initiator. Asserted (low) 
indicates input. 

46 GND Ground Signal Ground. 

47 - 48 SH1_BSY L DSSI BUSY. This is an "OR-tied" 
signal indicating the bus is 
being used. 

49 GND Ground Signal Ground. 

50 GND Ground Signal Ground. 

51 GND Ground Signal Ground. 

52 GND Ground Signal Ground. 
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Table G—1 (Cont.) KA680 Console Connector (J2) Pinout 


Pin Signal Name Usage Meaning 


53 TXD H Ethernet Console Terminal Data 
Out. This signal outputs 
serial character data 
from the console terminal 


transmitter. 
54 GND Ground Signal Ground. 
55 RXD H Ethernet Console Terminal Data 


In. This signal inputs 
serial character data to the 
console terminal receiver. 


56 GND Ground Signal Ground. 


57 TB25K H Console This is the 25.6 KHz 
oscillator from the H3604 
console module, which 
supplies the timebase for 
the time-of-year (TOY) 


clock. 

58 GND Ground Signal Ground. 

59 TDATA H Ethernet This is the transmit data 
signal. 

60 GND Ground Signal Ground. 

61 XMTEN H Ethernet This is the transmit enable 
signal. 

62 GND Ground Signal Ground. 

63 RCAR H Ethernet This is the receive enable 
signal. 

64 GND Ground Signal Ground. 

65 COL H Ethernet Collision Detect. 

66 GND Ground Signal Ground. 

67 RDATA H Ethernet RECEIVE DATA. 

68 GND Ground Signal Ground. 

69 TCLK H Ethernet Transmit Clock. 

70 GND Ground Signal Ground. 

71 RCLK H Ethernet Receive Clock. 

72 GND Ground Signal Ground. 

73 BITRATE <2> L Console Bit rate field bit 2. 

74 BITRATE <1>L Console Bit rate field bit 1. 

75 BITRATE <0> L Console Bit rate field bit 0. 

76 LEDCODE <3> L Console This is bit 3 (MSB) of the 


LED code going to the 
hexadecimal display on the 
console module. 
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Table G—1 (Cont.) KA680 Console Connector (J2) Pinout 


Pin Signal Name Usage Meaning 

77 LEDCODE <2> L Console This is bit 2 of the 
LED code going to the 
hexadecimal display on the 
console module. 

78 LEDCODE <1> L Console This is bit 1 of the 
LED code going to the 
hexadecimal display on the 
console module. 

719 LEDCODE <0> L Console This is bit 0 (LSB) of the 
LED code going to the 
hexadecimal display on the 
console module. 

80 VDDI H Console This pin is in the battery 
back-up supply for the SSC 
TOY clock. 

81 DSSI1_UID <2> L DSSI DSSI #1 Node 
Identification (ID) number 
bit 2 (MSB). 

82 DSSI1_UID <1> L DSSI DSSI #1 Node 
Identification (ID) number 
bit 1. 

83 DSSI1_UID <0> L DSSI DSSI #1 Node 
Identification (ID) number 
bit 0 (LSB). 

84 DSSI2_UID <2> L DSSI DSSI #2 Node 
Identification (ID) number 
bit 2 (MSB). 

85 DSSI2_UID <1> L DSSI DSSI #2 Node 
Identification (ID) number 
bit 1. 

86 DSSI2_UID <0> L DSSI DSSI #2 Node 
Identification (ID) number 
bit 0 (LSB). 

87 BOOTDIAG<1> L Console Boot and Diagnostic Code 
bit 1. 

88 BOOTDIAG<0> L Console Boot and Diagnostic Code 
bit 0. 

89 ENBHALT L Console The HALT ENABLE Bit. 

90 BTRYBAD H Console This is the battery bad 
signal that comes from the 
console module and goes to 
the battery sense circuitry. 

91 NC - - 

92 NC - - 

93 NC - - 

94 NC - - 

95 NC - - 
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Table G—1 (Cont.) KA680 Console Connector (J2) Pinout 


Pin Signal Name Usage Meaning 

96 NC - - 

97 NC - - 

98 NC - - 

99 NC - - 

100 CABLE_OK_IN L Console This pin is used to indicate 
if the cable is properly 
installed. 


Specifications G-11 


Specifications 
G.3 DC Power Consumption 


G.3 DC Power Consumption 


The KA680 CPU and MS690 memory module power requirements are as follows: 


Current (Amps) Power Q22-Bus Loads 
Module (Watts) |==-=ss-fes-aSa> 
+5 Vde | +3.3 Vdc] +12 Vde | -12 Vde (total) ac de 
MS690-BA 5.3 A 0.0 A 0.0 A 0.0 A 26.5 W 0 0 
MS690-CA 4.2 3B 0.0 A 0.0 A 0.0 A 21.0 W 0 0 
MS690-DA 6.4 A 0.0 A 0.0 A 0.0 A 32.0 W 0 0 
KA680-AA (3) 2.8 A 3.24 0.0 A 0.0 A 24.6 W 4 1 
KA680-AA (4) 4.8 3A 3.2 A 1.6A 0.0 A 53.8 W 4 1 
NOTE: 1) MS690 Current and Wattage values are unique depending on option. 
2) Memory modules are in dedicated slots 4 through 1. 
3) Power data includes CPU module only. 
4) Power power data includes CPU module, H3604 & Backplane power. 


G.4 Battery Back-up Specifications 


G.5 Opera 


G-12 Specificati 


When dc power is supplied to the KA680 module, it charges the external batteries 
from +5 volts through a 240-ohm resistor. 


When dc power is removed from the KA680 module, it drains the external 
batteries at a rate of 1.0 milliampere. 


Note 


These batteries supply power to the KA680 time-of-year clock and SSC 
RAM only. There is no battery backup for the memory system. 


ting Conditions 


The KA680 module will meet or exceed the requirements for operation in a DEC 
Standard 102 Class B system environment. This includes an allowed 5°C rise for 
box preheating of the air. 


TEMPERATURE 


+5°C to +45°C (+40°F to +113°F) with a rate of change no greater than 20°C +2°C 
(36°F +4°F) per hour at sea level. The maximum temperature must be derated by 
1.8°C per 1000 meters (1°F per 1000 feet) above sea level. 


HUMIDITY 


10% to 95% noncondensing, with a maximum wet bulb temperature of 32°C 
(90°F) and a minimum dew point temperature of 2°C (36°F). 


ALTITUDE 


ons 
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Up to 2,400 meters (8,000 feet) with a rate of change no greater than 300 meters 
per minute (1000 feet per minute). 


AIRFLOW 


The airflow required to meet these specifications is 200 lfm. 


G.6 Nonoperating Conditions (Fewer Than 60 Days) 
TEMPERATURE 


-40°C to +66°C (-40°F to +151°F) with a rate of change no greater than 11°C +2°C 
(20°F +4°F) per hour at sea level. The maximum temperature must be derated by 
1.8°C per 1000 meters (1°F per 1000 feet) above sea level. 


HUMIDITY 
Up to 95% noncondensing. 
ALTITUDE 
Up to 4,900 meters (16,000 feet) with a rate of change no greater than 600 meters 
per minute (2000 feet per minute). 
G.7 Nonoperating Conditions (More Than 60 Days) 
TEMPERATURE 


+5°C to +60°C (-40°F to +140°F) with a rate of change no greater than 20°C +2°C 
(36°F +4°F) per hour at sea level. The maximum temperature must be derated by 
1.8°C per 1000 meters (1°F per 1000 feet) above sea level. 


HUMIDITY 


10% to 95% noncondensing, with a maximum wet bulb temperature of 32°C 
(90°F) and a minimum dew point temperature of 2°C (36°F). 


ALTITUDE 


Up to 2,400 meters (8,000 feet) with a rate of change no greater than 300 meters 
per minute (1000 feet per minute). 


G.8 Mean Time Between Failures (MTBF) Estimate 


The estimated module failure rate for the KA680 is one error per 322,000 hours 
at 32°C. 


The estimated failure rate at 32°C for the MS690 memory modules are as follows: 


Module MTBF (Hours) 

MS690-BA (32 MB) 210,000 (With ECC off) 
MS690-BA 417,000 (With ECC on) 
MS690-CA (64 MB) 118,000 (With ECC off) 
MS690-CA 426,000 (With ECC on) 
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VAX Instruction Set 


The information in this appendix is for reference only. 

The standard notation for operand specifiers is: 
<name>.<access type><data type> 

where: 


1. Name is a suggested name for the operand in the context of the 
instruction. It is the capitalized name of a register or block 
for implied operands. 


2. Access type is a letter denoting the operand specifier access 
type. 


= address operand 

= branch displacement 

modified operand (both read and written) 

= read-only operand 

= if not "Rn", same as a, otherwise R[n+1]’R[n] 
= write-only operand 


Bab B OM 
iT 


3. Data type is a letter denoting the data type of the operand. 


b = byte 

= d_floating 

= f_floating 

= g_floating 

= longword 

quadword 

= field (used only in implied operands) 

= word 

= multiple longwords (used only in implied operands) 


+e GQraQ ma 
i 


4. Implied operands, that is, locations accessed by the 
instruction, but not specified in an operand, are denoted by 
curly braces {}. 


The abbreviations for condition codes are: 


kos conditionally set/cleared 
= not affected 

0 = cleared 

1 = set 


The abbreviations for exceptions are: 
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rsv 
lov 
idvz 
fov 
fuv 
fdvz 
dov 
ddvz 
sub 
prv 


reserved operand fault 
integer overflow trap 
integer divide by zero trap 
floating overflow fault 
floating underflow fault 


floating divide by zero fault 


decimal overflow trap 
decimal divide by zero trap 
subscript range trap 
privileged instruction fault 


Integer Arithmetic and Logical Instructions 


Opcode Instruction 

58 ADAWI add.rw, sum.mw 

80 ADDB2 add.rb, sum.mb 

(oid) ADDL2 add.rl, sum.ml 

AO ADDW2 add.rw, sum.mw 

81 ADDB3 addl.rb, add2.rb, sum.wb 
Cl ADDL3 addl.rl, add2.rl, sum.wl 
Al ADDW3 addl.rw, add2.rw, sum.ww 
D8 ADWC add.rl, sum.ml 

718 ASHL cnt.rb, src.rl, dst.wl 
79 ASHQ cnt.rb, src.rg, dst.wq 
8A BICB2 mask.rb, dst.mb 

CA BICL2 mask.rl, dst.ml 

AA BICW2 mask.rw, dst.mw 

8B BICB3 mask.rb, src.rb, dst.wb 
CB BICL3 mask.rl, src.rl, dst.wl 
AB BICW3 mask.rw, src.rw, dst.ww 
88 BISB2 mask.rb, dst.mb 

C8 BISL2 mask.rl, dst.ml 

A8 BISW2 mask.rw, dst.mw 

89 BISB3 mask.rb, src.rb, dst.wb 
C9 BISL3 mask.rl, src.rl, dst.wl 
AY BISW3 mask.rw, src.rw, dst.ww 
93 BITB mask.rb, src.rb 

D3 BITL mask.rl, src.rl 

B3 BITW mask.rw, src.rw 

94 LRB dst.wb 

D4 LRL{=F} dst.wl 

TC LRQ{=D=G} dst.wq 

B4 LRW dst.ww 

91 CMPB srcl.rb, src2.rb 

D1 CMPL srcl.rl, src2.rl 

Bl CMPW srcl.rw, src2.rw 

98 CVIBL src.rb, dst.wl 

99 CVIBW src.rb, dst.wl 

F6 CVTLB src.rl, dst.wh 

F7 CVTLW src.rl, dst.ww 

33 CVIWB src.rw, dst.wh 

32 CVIWL src.rw, dst.wl 
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+ FF F FF HF 


+ F FF FF HF 


eo 


CS) 3. a a oOCO OG oOo oOo oOo oOo oOo 


CoCOCCCO 


Exceptions 


lov 
lov 
lov 


DEC 


DEC 


DIV. 
DIV 
DIV 


DIV. 
DIV. 
DIV 


DECL 


B 


W 


B2 
L 2 
W2 


B3 
L 3 
W3 


EDIV 


EMU 


INC 
INC 
INC 


CO! 
CO! 
CO! 


NE 
NE 
NE 


UL 
UL 
UL 
UL 
PUS 


B 
L 
W 


B 
L 
MW 


GB 
GL 
GW 


OVB src. 
OVL src. 
OVQ src.r 
OVW src. 


B2 
L 2 
W2 


B3 
L 3 
W3 


HL 


dif.mb 
dif.ml 
dif.mw 


divr. 
divr. 
divr. 


divr. 
divr. 
divr. 


divr. 


rl, 
rw, 


rl, 


L mulr.rl, 


sum.mb 
sum.ml 
sum.mw 


src. 
src. 
src. 


src. 
src. 
src. 


OVZBW src. 
OVZBL src. 
OVZWL src. 


mulr. 
mulr. 
mulr. 


mulr. 
mulr. 
mulr. 


src. 


ROTL cnt.rb, 


rb, 
rl, 


rw, 


rl, 


quo.mb 
quo.ml 
quo .mw 


divd.rb, quo.wb 
divd.rl, quo.wl 
divd.rw, quo.ww 


divd.rg, quo.wl, rem.wl 


muld.rl, add.rl, prod.wq 


muld.rb, prod.wb 
muld.rl, prod.wl 
muld.rw, prod.ww 


{-(SP) .wl} 


src.rl, dst.wl 


SBWC sub.rl, dif.ml 


SUB 
SUB 
SUB 


SUB 
SUB 
SUB 


TST 


TSTI 


TST 


XOR 
XOR 
XOR 


XOR 
XOR 
XOR 


B2 
L 2 
W2 


B3 
L 3 
W3 


B 


Li 


B2 
L 2 
12 
B3 
L 3 
W3 


sub. 
sub. 
sub. 


sub. 
sub. 
sub. 


rb, 
ely 
rw, 


rb, 
pele 
rw, 


src.rb 


srce.r 


zl 


src.rw 


mask. 
mask. 
mask. 


mask. 
mask. 
mask. 


rb, 
rl, 
rw, 


rb, 
rl; 
rw, 


dif.mb 
dif.ml 
dif.mw 


min.rb, dif.wb 
min.rl, dif.wl 
min.rw, dif.ww 


dst .mb 
dst .ml 
dst .mw 


src.rb, dst.whb 
srce.rl, dst.wl 
src.rw, dst.ww 
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KOKI 10v 
aera lov 
Bs B® lov 
ARO) lov, idvz 
*-k-'() iov, idvz 
el) iov, idvz 
Bog 1) lov, idvz 
ae oR) lov, idvz 
eh () lov, idvz 
= 3e-) lov, idvz 
* 00 
kk 10v 
kk 10v 
kk 10v 
* 0 = 
* 0 = 
* 0 = 
k ok 10v 
rat lov 
kk 10v 
* 0 = 
* 0 = 
* 0 — 
* 0 
* 0 — 
* 0 = 
* 0 me 
bi 0 lov 
Rak 40) lov 
x * 0 lov 
ee) lov 
ates) lov 
% i) lov 
* 0 — 
* 0 = 
hs a 2 lov 
Re he lov 
a A lov 
aie.) lov 
kok * 10v 
kk 10v 
k ok 10v 
* 00 
* 0 0 
* 00 
* 0 = 
* 0 = 
* 0 = 
* 0 = 
* 0 = 
* 0 = 
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Address Instructions 


Opcode Instruction 


oR MOVAB src.ab, dst.wl 

DE MOVAL{=F} src.al, dst.wl 

TE MOVAQ{=D=G} src.aq, dst.wl 

3E MOVAW src.aw, dst.wl 

oF PUSHAB src.ab, {-(SP).wl} 

DF PUSHAL{=F} src.al, {-(SP).wl} 
TF PUSHAQ{=D=G} src.aq, {-(SP).wl} 
3F PUSHAW src.aw, {-(SP).wl} 


Variable Length Bit Field Instructions 


Opcode Instruction 


EC CMPV pos.rl, size.rb, base.vb, {field.rv}, src.rl 

ED CMPZV pos.rl, size.rb, base.vb, {field.rv}, srce.rl 

EE EXTV pos.rl, size.rb, base.vb, {field.rv}, dst.wl 

EF EXTZV pos.rl, size.rb, base.vb, {field.rv}, dst.wl 

FO INSV src.rl, pos.rl, size.rb, base.vb, {field.wv} 

EB FFC startpos.rl, size.rb, base.vb, {field.rv}, findpos.wl 
EA FFS startpos.rl, size.rb, base.vb, {field.rv}, findpos.wl 


Control Instructions 


Opcode Instruction 


F2 


DTANWUODUP BAW HE 


| 
Or 


(ro 2 | 
New 


| 
a 


ACBB limit.rb, add.rb, 
ACBL limit.rl, add.rl, 
ACBW limit.rw, add.rw, 


AOBLEQ limit.rl, index. 
AOBLSS limit.rl, index. 


BCC{=BGEQU} displ.bb 
BCS{=BLSSU} displ.bb 
BEQL{=BEQLU} displ.bb 
BGEQ displ.bb 

BGTR displ.bb 

BGTRU displ.bb 

BLEQ displ.bb 

LEQU displ.bb 

LSS displ.bb 
NEQ{=BNEQU} displ.bb 
VC displ.bb 

VS displ.bb 


BCC pos.rl, base.vb, 
BCS pos.rl, base.vb, 
BSC pos.rl, base.vb, 
BSS pos.rl, base.vb, 


BCCI pos.rl, base.vb, 
BSSI pos.rl, base.vb, 


WW WBDWWW WBDW WBWwoww 
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index.mb, displ.bw 
index.ml, displ.bw 
index.mw, displ.bw 


ml, displ.bb 
ml, displ.bb 


BC pos.rl, base.vb, displ.bb, {field.rv} 
BS pos.rl, base.vb, displ.bb, {field.rv} 


displ.bb, {field.mv} 
displ.bb, {field.mv} 
displ.bb, {field.mv} 
displ.bb, {field.mv} 


displ.bb, {field.mv} 
displ.bb, {field.mv} 


DOOOd CACC 


=). >: 
cts 
<=) <> 
Coo 


Exceptions 


Exceptions 


rsv 
rsv 


rsv 
rsv 
rsv 
rsv 


rsv 
rsv 


BLBC src.rl, displ.bb 
BLBS src.rl, displ.bb 


BRB displ.bb 
BRW displ.bw 


BSBB displ.bb, {-(SP) .wl} 
BSBW displ.bw, {-(SP).wl} 


CASEB selector.rb, base.rb, limit.rb, displ.bw-list 
CASEL selector.rl, base.rl, limit.rl, displ.bw-list 
CASEW selector.rw, base.rw, limit.rw, displ.bw-list 


JMP dst.ab 

JSB dst.ab, {-(SP).wl} 
RSB {(SP)+.rl} 

SOBGEQ index.ml, displ.bb 
SOBGTR index.ml, displ.bb 


Procedure Call Instructions 


Opcode 


Instruction 


CALLG arglist.ab, dst.ab, {-(SP) .w*} 
CALLS numarg.rl, dst.ab, {-(SP).w*} 
RET {(SP)+.r*} 


Miscellaneous Instructions 


Opcode 


Instruction 


BICPSW mask. rw 
BISPSW mask. rw 
BPT {-(KSP) .w*} 
HALT {-(KSP) .w*} 


INDEX subscript.rl, low.rl, high.rl, size.rl, indexin.rl, 
indexout.wl 


MOVPSL dst.wl 

NOP 

POPR mask.rw, {(SP)+.r*} 
PUSHR mask.rw, {-(SP) .w*} 


XFC {unspecified operands} 
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xk QO * 

xk QO * 

xk QO * 

es iov 
RES iov 
NZVC Exceptions 


k kK Kk rsv 
NZVC Exceptions 
kk kK rsv 

k kK kK rsv 
0000 

---- prv 

** 0 0 sub 
0000 
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Queue Instructions 


Opcode Instruction 


5c INSQHI entry.ab, header.aq 
5D INSQTI entry.ab, header.aq 
OE INSQUE entry.ab, pred.ab 
SE REMQHI header.aq, addr.wl 
SF REMQTI header.aq, addr.wl 
OF REMQUE entry.ab, addr.wl 


Operating System Support Instructions 


Opcode Instruction 


BD CHME param.rw, {-(ySP) .w*} 

BC CHMK param.rw, {-(ySP) .w*} 

BE CHMS param.rw, {-(ySP) .w*} 

BF CHMU param.rw, {-(ySP) .w*} 
Where y=MINU(x, PSL<CURRENT_MODE>) 

06 LDPCTX {PCB.r*, -—(KSP) .w*} 

DB MFPR procreg.rl, dst.wl 

DA MTPR src.rl, procreg.rl 

0c PROBER mode.rb, len.rw, base.ab 

OD PROBEW mode.rb, len.rw, base.ab 

02 REI {(SP)+.r*} 

07 SVPCTX {(SP)+.r*, PCB.w*} 


Floating-Point Instructions 


Opcode Instruction 


60 ADDD2 add.rd, sum.md 

40 ADDF2 add.rf, sum.mf 

40FD ADDG2 add.rg, sum.mg 

61 ADDD3 addl.rd, add2.rd, sum.wd 
41 ADDF3 addl.rf, add2.rf, sum.wf 
41FD ADDG3 addl.rg, add2.rg, sum.wg 
71 CMPD srcl.rd, src2.rd 

51 CMPF srcl.rf, src2.rf 

C 


PG srcl.rg, src2.rg 
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ea 
eo 

oO°O oOo oOo 

oOo oOo oOo 


Exceptions 


rsv 


rsv 


Exceptions 


rsv, prv 
rsv, prv 


rsv, prv 


rsv 


prv 


Exceptions 


rsv, fov, fuv 
rsv, fov, fuv 
rsv, fov, fuv 


rsv, fov, fuv 
rsv, fov, fuv 
rsv,fov, fuv 


rsv 
rsv 
rsv 


RPROBRKBTOKRHBRWABHROW 
co Re? Pa De 
whehok es) 


BOBS 
DD BWW VVVUTHAAAoYPwwooPrPond 


| 
iw) 


CVTBD src. 
CVIBF src. 
CVTBG src. 
CVTIDB src. 
CVIDF src. 
CVIDL src. 
CVIDW src. 
CVTFB src. 
CVTFD src. 
CVTIFG src. 
CVTIFL src. 
CVTFW src. 
CVTIGB src. 
CVIGF src. 
CVIGL src. 
CVTIGW src. 
CVTLD src. 
CVTILF src. 
CVTLG src. 
CVIWD src. 
CVIWF src. 
CVIWG src. 


CVTRDL src. 
CVTRFL src. 
CVTRGL src. 


DIVD2 divr. 


Li 
Li 


SUBD2 sub. 
SUBF2 sub. 
SUBG2 sub. 


SUBD3 sub. 
SUBF3 sub. 
SUBG3 sub. 


DIVF2 divr. 


DIVG2 divr. 


DIVD3 divr. 
DIVF3 divr. 


DIVG3 divr. 


F2 mulr. 
LG2 mulr. 


LD3 mulr. 
LF3 mulr. 
LG3 mulr. 


CG, 
rd, 
rf, 


rg, 


rd, 
rf, 


dst .wd 
dst .wf 
dst .wg 
dst .wb 
dst .wf 
dst .wl 
dst .ww 
dst .wb 
dst .wd 
dst .wg 
dst .wl 
dst .ww 
dst .wb 
dst .wf 
dst .wl 
dst .ww 
dst .wd 
dst .wf 
dst .wg 
dst .wd 
dst .wf 
dst .wg 


dst. 
dst. 
dst. 


quo 


quo. 


quo. 


wl 
wl 
wl 


.md 


mf 


mg 


divd.rd, quo.wd 


divd.rf, quo.wf 


divd.rg, quo.wg 


NEGD src.rd, dst.wd 
NEGF src.rf, dst.wf 
INEGG src.rg, dst.wg 


OVD src.rd, dst.wd 
OVF src.rf, dst.wf 
OVG src.rg, dst.wg 


D2 mulr. 


prod.md 
prod.mf 
prod.mg 


muld.rd, prod.wd 
muld.rf, prod.wf 
muld.rg, prod.wg 


dif. 
dif. 
dif. 
min. 
min. 
min. 


md 
mf 
mg 
rd, dif.wd 


rf, dif.wf 
rg, dif.wg 


a a ee. a. i ae a ee ee i, a | i i ee. | 2 


cts 
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+ FF FF F HF HF HF FHF HF HF HF FHF HF HF HF FHF HF HK HF HF FH 


ce 


> SS SS oe SS ES ES EE ES 


+ > 


DOO COO COO COAC® 


oOOd COO 


Oo COCO CCC COCOCOCOCOCOCOOCOCOCOOCOOCOCOOOCOCOCCOem 


CoOoOOoO COCO 


rsv, iov 
rsv, fov 
rsv, iov 
rsv, iov 
rsv, iov 
rsv 

rsv 

rsv, iov 
rsv, iov 
rsv, iov 
rsv, fov, fuv 
rsv, iov 
rsv, iov 


rsv, iov 
rsv, iov 
rsv, iov 


rsv,fov, fuv, 
fdvz 
rsv,fov, fuv, 
fdvz 
rsv,fov, fuv, 
fdvz 


rsv,fov, fuv, 
fdvz 
rsv, fov, fuv, 
fdvz 
rsv,fov, fuv, 
fdvz 


rsv 
rsv 
rsv 


rsv 
rsv 
rsv 


rsv, fov, fuv 
rsv, fov, fuv 
rsv, fov, fuv 


rsv, fov, fuv 
rsv, fov, fuv 
rsv, fov, fuv 


rsv, fov, fuv 
rsv, fov, fuv 
rsv, fov, fuv 


rsv, fov, fuv 
rsv, fov, fuv 
rsv, fov, fuv 
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VAX Instruction Set 


713 TSTD srce.rd ** 0 0 rsv 
53 TSTF sre.rf ** 0 0 rsv 
53FD TSTG srce.rg ** 0 0 rsv 
Microcode-Assisted Emulated Instructions 
The NVAX CPU provides microcode assistance for the macrocode 
emulation of these instructions. The CPU processes the operand specifiers, 
creates a standard argument list, and invokes an emulation routine to 
perform emulation. 
Opcode Instruction NZVC Exceptions 
20 ADDP4 addlen.rw, addaddr.ab, sumlen.rw, sumaddr.ab eT ak eG) rsv, dov 
21 ADDP6 addllen.rw, addladdr.ab, add2len.rw, add2addr.ab, ey iO) rsv, dov 
sumlen.rw, sumaddr.ab 
F8 ASHP cnt.rb, srclen.rw, srcaddr.ab, round.rb, AVE EO rsv, dov 
dstlen.rw, dstaddr.ab 
35 CMPP3 len.rw, srcladdr.ab, src2addr.ab ** 00 
37 CMPP4 srcllen.rw, srcladdr.ab, src2len.rw, src2addr.ab * 070 
OB CRC tbhl.ab, inicrc.rl, strlen.rw, stream.ab e100 
F9 CVILP src.rl, dstlen.rw, dstaddr.ab ke Al) rsv, dov 
36 CVIPL srclen.rw, srcaddr.ab, dst.wl cae ae dael rsv, lov 
08 CVIPS srclen.rw, srcaddr.ab, dstlen.rw, dstaddr.ab eee 0) rsv, dov 
09 CVISP srclen.rw, srcaddr.ab, dstlen.rw, dstaddr.ab oe RE IQ) rsv, dov 
24 CVTPT srclen.rw, srcaddr.ab, tbladdr.ab, ee ey iO) rsv, dov 
dstlen.rw, dstaddr.ab 
26 CVITP srclen.rw, srcaddr.ab, tbladdr.ab, AEN O) rsv, dov 
dstlen.rw, dstaddr.ab 
27 DIVP divrlen.rw, divraddr.ab, divdlen.rw, divdaddr.ab, xe #0 rsv,dov, ddvz 
quolen.rw, quoaddr.ab 
38 EDITPC srclen.rw, srcaddr.ab, pattern.ab, dstaddr.ab BGR GR, rsv, dov 
39 [ATCHC objlen.rw, objaddr.ab, srclen.rw, srcaddr.ab 0* 00 
34 OVP len.rw, srcaddr.ab, dstaddr.ab ** 0 0 
2E OVTC srclen.rw, srcaddr.ab, fill.rb, tbladdr.ab, cmc Vis? 
dstlen.rw, dstaddr.ab 
2F OVTUC srclen.rw, srcaddr.ab, esc.rb, tbladdr.ab, Re ee 
dstlen.rw, dstaddr.ab 
25 ULP mulrlen.rw, mulraddr.ab, muldlen.rw, muldaddr.ab, BGR 0) rsv, dov 
prodlen.rw, prodaddr.ab 
22 SUBP4 sublen.rw, subaddr.ab, diflen.rw, difaddr.ab et 10 rsv, dov 
23 SUBP6 sublen.rw, subaddr.ab, minlen.rw, minaddr.ab, $F) rsv, dov 


diflen.rw, difaddr.ab 
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Address Assignments 


This appendix provides a map of the VAX memory space. 


Il.1 KA680 General Local Address Space Map 


VAX Memory Space 


1FFF 


0000 


Contents 


Local Memory Space (512 MB) 


Contents 
Local Q22-bus I/O Space (8 KB) 
Reserved Local I/O Space (248 KB) 


Local Register I/O Space (1.5 MB) 


Reserved Local I/O Space (62.5 
Reserved Local 1/0 Space (64 MB 
Reserved Local I/0 Space (64 MB 
Reserved Local I/0 Space (64 MB 


Reserved Local I/O Space (60 


Local Q22-bus Memory Space (4 MB) 
) 
Reserved Local I/0 Space (64 MB) 


Reserved Local 1/0 Space (64 
Reserved Local 1/0 Space (64 


Local ROM Space 


Address Assignments [+1 


Address Assignments 
1.2 KA680 Detailed Local Address Space Map 


1.2 KA680 Detailed Local Address Space Map 


Local Memory Space (up to 512 MB) 0000 0000 - 1FFF FFFF 
Q22-bus Map - Top 32 KB of Main Memory 


VAX I/O Space 


Local Q22-bus I/0 Space 2000 0000 - 2000 1FFF 
Reserved Q22-bus I/0 Space 2000 0000 - 2000 0007 
Q22-bus Floating Address Space 2000 0008 - 2000 O7FF 
User Reserved Q22-bus 1/0 Space 2000 0800 - 2000 OFFF 
Reserved Q22-bus I/0 Space 2000 1000 - 2000 1F3F 
Interprocessor Comm Reg 2000 1F40 
Reserved Q22-bus I/0 Space 2000 1F44 - 2000 1FFF 

Local Register I/O Space 2000 2000 - 2003 FFFF 
Reserved Local Register I/0 Space 2000 4000 - 2000 402F 
SHAC1 SSWCR 2000 4030 
Reserved Local Register I/0 Space 2000 4034 - 2000 4043 
SHAC1 SSHMA 2000 4044 
SHAC1 PQBBR 2000 4048 
SHAC1 PSR 2000 404C 
SHAC1 PESR 2000 4050 
SHAC1 PFAR 2000 4054 
SHAC1 PPR 2000 4058 
SHAC1 PMCSR 2000 405C 
Reserved Local Register I/0 Space 2000 4060 - 2000 407F 
SHAC1 PCQOCR 2000 4080 
SHAC1 PCQ1CR 2000 4084 
SHAC1 PCQ2CR 2000 4088 
SHAC1 PCQ3CR 2000 408C 
SHAC1 PDFQCR 2000 4090 
SHAC1 PMFQCR 2000 4094 
SHAC1 PSRCR 2000 4098 
SHAC1 PECR 2000 409C 
SHAC1 PDCR 2000 40A0 
SHAC1 PICR 2000 40A4 
SHAC1 PMTCR 2000 40A8 
SHAC1 PMTECR 2000 40AC 
Reserved Local Register I/0 Space 2000 40B0 - 2000 422F 


I-2. Address Assignments 


Address Assignments 
1.2 KA680 Detailed Local Address Space Map 


KA680 DETAILED LOCAL ADDRESS SPACE MAP (Cont.) 
SHAC2 SSWCR 2000 4230 
Reserved Local Register I/O Space 2000 4234 - 2000 4243 
SHAC2 SSHMA 2000 4244 
SHAC2 PQBBR 2000 4248 
SHAC2 PSR 2000 424C 
SHAC2 PESR 2000 4250 
SHAC2 PFAR 2000 4254 
SHAC2 PPR 2000 4258 
SHAC2 PMCSR 2000 425C¢ 
Reserved Local Register I/0 Space 2000 4260 - 2000 427F 
SHAC2 PCQOCR 2000 4280 
SHAC2 PCQICR 2000 4284 
SHAC2 PCQ2CR 2000 4288 
SHAC2 PCQ3CR 2000 428C 
SHAC2 PDFQCR 2000 4290 
SHAC2 PMFQCR 2000 4294 
SHAC2 PSRCR 2000 4298 
SHAC2 PECR 2000 429C¢ 
SHAC2 PDCR 2000 42A0 
SHAC2 PICR 2000 42A4 
SHAC2 PMTCR 2000 42A8 
SHAC2 PMTECR 2000 42AC 
Reserved Local Register I/0 Space 2000 42B0 - 2000 7FFF 
NICSRO - Vector Add, IPL, Sync/Async 2000 8000 
ICSR1 - Polling Demand Register 2000 8004 
CSR2 - Reserved 2000 8008 
NICSR3 - Receiver List Address 2000 800C 
NICSR4 - Transmitter List Address 2000 8010 
CSR5 - Status Register 2000 8014 
ICSR6 - Command and Mode Register 2000 8018 
ICSR7 - System Base Address 2000 801C 
NICSR8 - Reserved 2000 8020* 
ICSR9 - Watchdog Timers 2000 8024* 
CSR10- Reserved 2000 8028* 
NICSR11- Rev Num & Missed Frame Count 2000 802c* 
NICSR12- Reserved 2000 8030* 
CSR13- Breakpoint Address 2000 8034* 
ICSR14- Reserved 2000 8038* 
NICSR15- Diagnostic Mode & Status 2000 803C 
Reserved Local Register I/0 Space 2000 8040 - 2003 FFFF 
Q-22 Bus Local Register I/0 Space 2008 0000 - 201F FFFF 
DMA System Configuration Register 2008 0000 
DMA System Error Register 2008 0004 
DMA Master Error Address Register 2008 0008 
DMA Slave Error Address Register 2008 000C 
Q22-bus Map Base Register 2008 0010 
Reserved Local Register I/0 Space 2008 0014 - 2008 OOFF 
Error Status Register Reg 32 2008 0180 
emory Error Address Reg 33 2008 0184 
I/O Error Address Reg 34 2008 0188 
DMA Memory Error Address Reg 35 2008 018C 


DMA Mode Control and 
Diagnostic Status Register Reg 36 2008 0190 


Reserved Local Register I/0 Space 2008 0194 - 2008 3FFF 
Boot and Diagnostic Reg (32 Copies) 2008 4000 - 2008 407C 
Reserved Local Register I/0 Space 2008 4080 - 2008 7FFF 


Address Assignments I-3 


Address Assignments 
1.2 KA680 Detailed Local Address Space Map 


NCA CSRs 


Error Status Register 

Mode Control and Diagnostic Reg 
CP1 Slave Error Address Register 
CP2 Slave Error Address Register 
CP1 10 Error Address Register 
CP2 10 Error Address Register 
NDAL Error Address Register 


Local UVROM Space 
VAX System Type Register (In ROM) 
Local UVROM - (Halt-Protected) 


I-4 Address Assignments 


2102 
2102 
2102 
2102 
2102 
2102 
2102 


E004 
E004 
E004 


0000 
0004 
0008 
000C 
0010 
0014 
0018 


0000 - E007 FFFF 
0004 
0000 - E007 FFFF 


Address Assignments 
1.2 KA680 Detailed Local Address Space Map 


KREEKKKKKKKKKKKKK KKK KKK KKK KKK KKK KKK KKK KKK KKK KK KKKKKKKKKKKKKKKKKKKKKKKKK 


The following addresses allow those KA680 internal processor 
registers that are implemented in the SSC chip (external, internal 
processor registers) to be accessed via the local I/0 page. These 
addresses are documented for diagnostic purposes only and should 
not be used by nondiagnostic programs. 


Time-Of-Year Register 2014 006C 

Console Storage Receiver Status 2014 0070* 

Console Storage Receiver Data 2014 0074* 

Console Storage Transmitter Status 2014 0078* 

Console Storage Transmitter Data 2014 007C* 

Console Receiver Control/Status 2014 0080 

Console Receiver Data Buffer 2014 0084 

Console Transmitter Control/Status 2014 0088 

Console Transmitter Data Buffer 2014 008C 

Reserved Local Register I/O Space 2014 0090 - 2014 OODB 
I/O Bus Reset Register 2014 00DC 

Reserved Local Register I/0 Space 2014 O0EO 

Reserved Local Register I/O Space 2014 OOFC - 2014 OOFF 


* These registers are not fully implemented, accesses yield 
unpredictable results. 


KREEKKKKKKK KKK KKK KKK KK KKK KKK KKK KKK KKK KKK KK KKK KKK KKK KK KKK KKKKKKKKKKKKKKK 


Local Register I/O Space (Cont.) 

Timer 0 Control Register 2014 0100 

Timer 0 Interval Register 2014 0104 

Timer 0 Next Interval Register 2014 0108 

Timer 0 Interrupt Vector 2014 010C 

Timer 1 Control Register 2014 0110 

Timer 1 Interval Register 2014 0114 

Timer 1 Next Interval Register 2014 0118 

Timer 1 Interrupt Vector 2014 011C 

Reserved Local Register I/0 Space 2014 0120 - 2014 012F 

BDR Address Decode Match Register 2014 0140 

BDR Address Decode Mask Register 2014 0144 

Reserved Local Register I/0 Space 2014 0138 - 2014 03FF 

Battery Backed-Up RAM 2014 0400 - 2014 O7FF 

Reserved Local Register I/0 Space 2014 0800 - 201F FFFF 
Reserved Local 1/0 Space 2020 0000 - 2FFF FFFF 
Local Q22-bus Memory Space 3000 0000 - 303F FFFF 
Reserved Local Register I/0 Space 3040 0000 - 3FFF FFFF 


I.3 External, Internal Processor Registers 


Several of the internal processor registers (IPRs) on the KA680 are implemented in the NCA 
or SSC chip rather than the CPU chip. These registers are referred to as external, internal 


Address Assignments I-5 


Address Assignments 


1.3 External, Internal Processor Registers 


processor registers and are listed below. 


IPR # Register Name 


27 Time-of-Year Register 

28 Console Storage Receiver Status 

29 Console Storage Receiver Data 

30 Console Storage Transmitter Status 
31 Console Storage Transmitter Data 
32 Console Receiver Control/Status 

33 Console Receiver Data Buffer 

34 Console Transmitter Control/Status 
35 Console Transmitter Data Buffer 

55 I/O System Reset Register 


* These registers are not fully implemented, accesses yield 
unpredictable results. 


1.4 Global Q22—bus Address Space Map 


Q22-bus Memory Space 


Q22-bus Memory Space 


(Octal) 0000 0000 


Q22-bus I/0 Space (BBS7 Asserted) 


Q22-bus I/O Space (Octal) 1776 0000 
Reserved Q22-bus I/0 Space 1776 0000 
Q22-bus Floating Address Space 1776 0010 
User Reserved Q22-bus I/0 Space 1776 4000 
Reserved Q22-bus I/0 Space 1777 0000 
Interprocessor Comm Reg 1777 7500 
Reserved Q22-bus I/0 Space 1777 7502 


I-6 Address Assignments 


1777 


1777 
1776 
1776 
1776 
TEL 


aly ae 


TEA 


7777 
0007 
3777 
7777 
T7477 


7777 


J 


Configurable Machine State 


The KA680 CPU module has many control registers that need to be configured 
for proper operation of the module. The following list shows the normal state 
of all configurable bits in the CPU module as they are left after the successful 
completion of power-up ROM diagnostics. 


NCA_CSR1: Mode Control and Diagnostic Status Register (2102 0004) 
15:14: CP2 MT Timer Prescaler 

11 = 144000 cycles* - needed for CQBIC 10 ms No Grant 
timeout 


13:12: CP1 MT Timer Prescaler 
00 = 144 cycles - minimum for passive releases, no 
cycle should take longer than this 


11:10: NDAL Timeout Prescaler 

00 = 3200 cycles* - this is longer than both NCA and 
NMC transactions timeouts, preserves timeout 
order 


9: QBUS_TRANS enable (formerly CQBIC_PRESENT) 
0 = QBUS_TRANS signal disabled* - 


8: I02 ID enable 
1 = enabled 


de Force wrong CP2 bus parity 
0 = off* - diagnostic use only 


6: Force wrong CP1 bus parity 
0 = of f* - diagnostic use only 


ae Force wrong NDAL master parity 
0 = off* - diagnostic use only 


4; Force wrong NDAL slave parity 
0 = off* - diagnostic use only 


3: Enable prefetch 
1 = enable CP bus prefetch on DMA reads 


2: Force write buffer hit 
0 = off* - diagnostic use only 


aes Force CP2 bus owner 
0 = disabled - diagnostic use only 


0: Force CP1 bus owner 
0 = disabled - diagnostic use only 
ICCS: Interval Clock Control and Status Register (2100 0060) 
NOTE: VMS sets ICCS, NICR to proper values 


6: Interrupt enable 
0 = disabled* 


Configurable Machine State J-1 


Configurable Machine State 


NICR: 


MEMCON0-7: 


MMCDSR 


J-—2 Configurable Machine State 


Single step 
0 = of f* 


Transfer 
0 = disabled* 


Run - increment every 1 us 
0 = do not increment* 


Next Interval Count Register (2100 0064) 
31:0 


Initial count value for ICR (FFFFD8F0* (10 ms)) 


Memory Configuration Registers (2101 8000 through 2101 801C) 


NOTE: Diagnostics set these registers based on available memory 


31s 


28:24: 


Base Address Valid 
0 not valid* 
1 = valid 


Base Address (0 on reset) 
1 MB RAM - all address bits used 
4 MB RAM - only <28:26> used 


10 = 4 MB RAM 
= nonexistent bank 


bh 
be 
| 


ode 
1 = 64-bit mode 


Mode Control and Diagnostic Status Register (2101 8048) 


31st 


30: 


2933 


28: 


27: 


ches 


Fast Diagnostic Mode (FDM) 
0 = disabled* - diagnostic use only 


FDM Second pass 
0 = disabled* - diagnostic use only 


Diagnostic Checkbit mode 
0 = disabled* - diagnostic use only 


QBus on I01 
0 = QBus on I02* 


Enable soft error log (NDAL & memory related) 
0 = disabled* - VMS enables this 


Flush BCache 
0 = don’t flush* 


emory diagnostic check bits 
0 - meaningful only in diagnostic check mode* (may or 
may not be read as 0) 


NDAL Timeout Scaler 
00 = 2600 cycles* - maximum, to preserve timeout order 


Disable memory error 
0 = memory errors deteted and corrected* 


Refresh interval timer select 
0 = 328 cycles* 


Force wrong parity on NDAL transactions 
0 = of f* - diagnostic use only 


Disable memory refresh 
0 = memory refreshed* 


Configurable Machine State 


0: Force refresh 
0 = normal refresh* 


MOAMR : O-bit Address and Mode Register (2101 804C) 
16: Ignore O-bit mode 
0 = O-bits checked* 
15: Disable O-bit error 


0 = O-bit errors detected* 


14:6:  O-bit segment address (0*) - meaningful only during 
O-bit data register access 


533s O-bit mask (0*) - meaningful only during O-bit data 
register access 


2:0: O-bit operation mode 
000 = reconstruction mode* - meaningful only during 
O-bit data register access 


MODR O-bit Data Registers (2101 0000 through 2101 7FFF) 
23:12: O-bit field 1 (0*) - used only during Fast Memory test 


11:0:  O-bit field 0 (0*) - used only during Fast O-bit test 


mode 
NVAX 
CPUID: CPU ID Register (IPR E) 
7:0: CPU identifcation = 0 (for single processor config.) 
SID: System Identification Register (IPR 3E) 
NOTE: This register may only be written by microcode 
31:24: CPU type - 13hex (NVAX code) 
13:8: Patch revision 
7:0: Microcode revision 
ICSR: IBox Control and Status Register (IPR D3) 
0: VIC enable 
1 = enabled 
ECR: EBox Control Register (IPR 7D) 
13% FBox test enable 
0 = disabled* - diagnostic use only 
7% Interval time mode 
1 = full CPU implemented interval timer 
os $3 stall timeout 
0 = counts cycles w/ timeout_enable asserted* (~3 sec) 
33 FBox stage 4 bypass 
1 = enabled - result from stage 3 passed directly to 
FBox output interface (improves FBox latency) 
2% S3 external time base timeout 
0 = disabled* - use internal time base 
Lis FBox enable 
1 = enabled 
0: Vector present 
0 = no* - no vector option available at this time 
MMAPEN: Memory Map Enable Register (IPR E6) 
08 Memory map enable 


0 = disabled* - VMS enables this 


Configurable Machine State J-3 


Configurable Machine State 


PAMODE: Physical Address Mode Register (IPR E7) 
0: Physical address mode 
0 = 30-bit physical address space* 


PCCTL: PCache Control Register (IPR F8) 
8: PCache Electrical disable 
Q = PCache enabled* 


se) MBox performance monitor mode 
Q - diagnostic use only* 


4; PCache error enable 
1 = enables PCache error detection 


3: Bank select during force hit mode 
0 = left bank selected if force hit mode enabled* 
- diagnostic use only 


Ze Force hit 
0 = disabled* - diagnostic use only 
1% I_enable 
1 = enable PCache for IREAD, INVAL, I_CF commands 
0: D_enable 
1 = enable PCache for INVAL, D-stream read/write/fill 
commands 
CCTLs CBox Control Register (IPR AQ) 
30: Software ETM 


0 = disabled* - diagnostic use only 


16: Force NDAL parity error 
0 = of f* - diagnostic use only 


15:11: Performance monitoring BCache access and hit type 
0 - configures BCache for performance monitoring* - 
meaningful only during performance monitoring 


10: Disable CBox write packer 
0 = write packer enabled* - improves write latency 


9 Read timeout counter test 
0 = test disabled* - use external time base for read 
timeout counter 


8: Software ECC 
0 = use correct ECC* 


7: Disable BCache errors 
0 = BCache errors detected* 


6: Force Hit 
0 = disabled* - diagnostic use only 


54s BCache size 
00 = 128 KB* (KA680) 


3:2: Data store speed 
01 = 3 cycle read, 4 cycle write 
1: Tag store speed 
1 = 4 cycle read, 4 cycle write 
0: Enable BCache 
1 = enabled 
CQBIC 
SCR: System Configuration Register (2008 0000) 
14: Halt enable 


1 = BHALT to CQBIC HALTIN pin to cause halts 


J—4 Configurable Machine State 


ICR: 


QBMBR: 


PPR: 


PMCSR: 


NICSRO: 


NICSR6: 


Configurable Machine State 


12: Page prefetch disable 
1 = map prefetch disabled - historical latency reasons 


Ae Restart enable 
0 = QBus restart causes ARB power-up reset* 


321s ICR offset address select bits 
0 = no effect (AUX mode not supported) * 


Interprocessor Communication Register (2000 1F40) 
oe AUX Halt 
0 = no halt (AUX mode not supported) 


6: ICR interrupt enable 
0 = interprocessor interrupts disabled - only 
uniprocessor config. allowed 


5 Local memory external access enable 
0 = external access disabled* - VMS will configure map 


Q-Bus Map Base Address Register (2008 0010) 
28:15: address where 8K QBus mapping register are located 
(undefined at reset) - VMS will configure map 


All SHAC registers are subsequently configured by VMS driver 


Port Queue Block Base Register (2000 4048) 

20:0: upper bits of physical address of base of Port Queue 
block. Contains HW version, FW version, shared host 
memory version and CI port maintenance ID at power-up. 


Port Parameter Register (2000 4058) 
31:29: Cluster size. For SHAC value = 0. 


28:16: Internal buffer length = 0* (For SHAC value = 1010 hex) 
7:0: Port number. Same as SHAC’s DSSI ID. 


Port Maintenance Control and Status Register (2000 405C) 
2% Interrupt enable 
0 = disabled* 


1: Maintenance timer disable 
0 = enabled* 


All SGEC registers are susequently configured by VMS driver 


Vector Address, IPL, Synch/Asynch Register (2000 8000) 
31:30: Interrupt priority 
00 = 14* 


29: Synch/Asynch bus master operating mode 
0 = asynchronous* 
15:0: Interrupt vector = 0003hex* 


Command and Mode Register (2000 8018) 
30: Interrupt enable 
0 = disabled* 


28:25: Burst limit mode 
maximum number of longwords transferred in a single DMA 
burst. 1*,2,4,8 when NICSR <19>is clear; 


1*,4 when set. 


20: Boot message enable mode 
0 = disabled* 
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Configurable Machine State 


19; Single cycle enable mode 
0 = disabled* 


11: Start/Stop transmission command 
0 = SGEC transmission process in stopped state* 


10: Start/Stop reception command 
0 = SGEC reception process in stopped state* 


9:8: Operating mode 
00 = normal mode* 


Tt Disable data chaining mode 
0 = frames too long for current receive buffer will be 
transferred to the next buffer(s) in receive list* 


6: Force collision mode (internal loopback mode only) 
0 = no collision* 


3% Pass bad frames mode 
0 = bad frames discarded* 


2218 Address filtering mode 
00 = normal mode* 


NICSR7: System Base Register (2000 801C) 
29:0: System base address - physical starting address of the 
VAX system page table (unpredictable after reset) 


NICSR9: Watchdog Timers Register (2000 8024) 
31:16: Receive watchdog timeout 
0 = never timeout* 
default = 1250 = 2 ms 
range = 72 ps (45) to 100 ms 


15:0: Transmit watchdog timeout 
0 = never timeout* 
default = 1250 = 2 ms 
range = 72 ps (45) to 100 ms 


SSC: 

SSCBAR: SSC Base Address Register (2014 0000) 
29:0 20140000 = Base address* 

SSCCR: SSC Configuration Register (2014 0010) 
ahs Interrupt vector disable 


0 = interrupt vector enabled* 


25:24: IPL Level 


00 = 14* 
23: ROM access time 
Q = 350 ns* 
22:20: ROM size 
101 = 256 KB 


18:16: Halt protected space 
101 = 20040000 - 2007FFFF (historical) 


15% Control P enable 
0 = only 20 spaces recognized as break* (historical) 


14:12: Terminal UART baud rate 
101 = 9600 (historical) 


6: Programmable address strobe 1 ready enable (for BDR) 
1 = ready asserted after address strobe 


5:4: Programmable address strobe 1 enable (for BDR) 
11 = read enabled, write enabled 


J-6 Configurable Machine State 


RXCS: 


TXCS: 


SSCBT: 


ADSO 


ADSO 


ADS1 


ADS1 


TICR: 


TICR: 


TNIR: 


TOIV: 


TLIV: 


TOY: 


[AT: 


IAS: 


[AT: 


IAS: 


130% 


Console 
6: 


Console 
6: 


SSC Bus 
23:0: 


Programn 
29523 


Progran 
29.22 


i=} 


Progran 
29328 


i= 


Progran 
29% 2: 


= 


Programn 
6: 


Configurable Machine State 


Programmable address strobe 0 ready enable 
0 = no ready after address strobe* - not used by Omega 


Programmable address strobe 0 enable 
00 = read disabled, write disabled* - not used by Omega 


Receiver Control and Status Register (2014 0080) 
Interrupt enable 
0 = disabled* - polled in console mode 


Transmitter Control and Status Register (2014 0088) 
Interrupt enable 
0 = disabled* 


Loopback enable 
0 = disabled* - diagnostic use only 


Break transmit 
0 = terminate SPACE condition* 


Time Out Register (2014 0020) 
Bus timeout interval = 4000hex (16.384 ms) 
range = 1 to FFFFFF (1 ps to 16.77 s) 


able Address Strobe 0 Match Register (2014 0130) 
atch address 
0 = disabled* - not used 


able Address Strobe 0 Mask Register (2014 0134) 
ask address bits - not used 


able Address Strobe 1 Match Register (2014 0140) 
atch address = 20084000 (for BDR) 


able Address Strobe 1 Mask Register (2014 0144) 
ask address bits = 7C (for BDR) 


able Timer 0 Control Register (2014 0100) 
Interrupt enable 
0 = disabled* 


STP 
0 = run after overflow* 


RUN 
0 = counter not running* (historical) 


Programmable Timer 1 Control Register (2014 0110) 


6: 


Interrupt enable 
0 = disabled* 


STP 
0 = run after overflow* 


RUN 
1 = counter incrementing every microsecond (historical) 


Programmable Timer Next Interval Registers (2014 0108, 


31:0: 


2014 0118) 
Timer next interval count (use 2’s complement) 
range = 0* to 1.2 hours 


Programmable Timer 0 Interrupt Vector Register (2014 010C) 


932% 


- 


imer interrupt vector = 78hex 


Programmable Timer 1 Interrupt Vector Registers (2014 011C) 


G2": 


Time of 
31:0: 


Timer interrupt vector = 7Chex 


Year Register (2014 006C) 
Number of 10 ms intervals since written 
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Configurable Machine State 


DLEDR: Diagnostic LED Register (2014 0030) 
3203 Display bits 
0 = LEDs on* (historical) 


J-8 Configurable Machine State 


A 


Address 
Q22-bus <21:9>, 9-7 
Addresses 
descriptor list, 10-9 
filtering mode, 10—20 
mulitcast, 10-2 
of NICSRx, 10-4 
physical, 10-2 
system base, 10-22 
Address Translation 
CDAL to Q22-bus, 9-7 
Q22-bus, 9-2 
Algorithm 
to find a valid RPB, 12-23 
to restart operating system, 12-22 
Areas not covered, 12-85 


Babbling SGEC Transmissions, 10-23 
Backplane Connections, G—1 
Backplane Connectors Used, 1-3 
Backplane wiring, F-35 
Bits 
cleared on power-up 
DMA QME, 9-9 
cleared on powerup 
ACTION ON DCOK NEGATION, 9-12 
AUX HLT, 9-9 
BHALT EN, 9-11 
CAMValid, 9-7 
DBI IE, 9-9 
LM EAE, 9-9 
LOST ERROR, 9-14 
MAIN MEMORY ERROR, 9-14 
NO GRANT TIMEOUT, 9-14 
POK, 9-11 
Q22-BUS DCOK NEGATION DETECTED, 
9-14 
SCR, 9-11 
NICSR access modes, 10-4 
RPB$V_DIAG, 12-20 
RPB$V_SOLICT, 12-20 
undefined on powerup 
A28-A9, 9-5 


Index 


Bits 
undefined on powerup (cont'd) 
QBMBR register, 9-10 
QBUS ADR, 9-7 
V, 9-5 
BLINK 
definition of, 11-4 
Block mode DMA, F-20 
BOOT, 12-12, 12-15, 12-35 
BOOT AND DIAGNOSTIC FACILITY, 8-1 
Battery Backed-up RAM, 8-6 
Boot and Diagnostic Register, 8-1 
Diagnostic LED Register, 8—4 
EPROM Memory, 8-5 
Initialization, 8-6 
Boot Block Format, 12-19 
Boot Devices, 12-14 
names, 12-14 
supported, 12-14 
Boot Flags, 12-15 
RPB$V_BBLOCK, 12-19 
Boot Message 
from the SGEC, 10-13 
Boot Message Enable Mode, 10-17 
Bootstrap 
automatic 
sample output, 12-17 
conditions, 12—12, 12-15 
definition of, 12-12 
device names, 12-35 
disk and tape, 12-19 
failure, 12-12 
initialization, 12-12 
memory layout, 12-13 
memory layout after successful bootstrap, 
12-17 
network, 12-20 
preparing for, 12-12 
primary, 12-16 
PROM, 12-20 
secondary, 12-16 
control passed to, 12-17 
supported, 12-87 
BREAK 
ignored, 12-26 
Broadcast Address, 10-3 


Index—1 


Buffer Format, 10-28 
Buffers 
perfect filtering setup frame, 10—40 
Burst Limit Mode 
SGEC, 10-17 
Burst Transfer Rate, 11-1 
Bus cycle protocol, F-6 
Bus drivers, F-33 
Bus Grant 
unreturned, 9-14 
Bus interconnecting wiring, F-35 
Bus length (DSSD, 2-7 
Bus receivers, F—34 
Bus termination, F-34 


C 

Cabling 
DSSI, 2-7 
ISE, 2-7 

Cache 


backup/secondary/second level, 1-5 
on the CQBIC, 9-6 
primary/first-level, 1-5 
Q22-bus interface, 9-5 
virtual instruction, 1-5 
Cache Memory 
Overview, 4-1 
Central Processing Unit, 1-4 
CENTRAL PROCESSING UNIT (CPU), 3-1 
CPU References, 3-46 
Data Types, 3-23 
General Purpose Registers 
see also REGISTERS 
Instruction Set, 3-23 
Internal Processor Registers 
see also REGISTERS 
Interrupts 
Priority Level, 3-30 
Intruction_Stream Read,, 3—46 
Memory Management Control Register, 3-28 
Processor State, 3-1 
Processor Status Longword, 3-2 
Process Structure, 3—23 
Software Interrupt Summary Register 
Definition of, 3-32 
System Control Block, 3-41 
Format of, 3-42 
System Identification, 3-44 
Translation Buffer, 3-27 
Write References, 3-48 
CENTRAL PROCESSING UNIT(CPU) 
Data-Stream Read, 3-48 
Disown Write, 3-48 
Ownership Read, 3-47 
Program Counter 
Definition of, 3-2 
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Central Processor, 3-1 
Chip Revision Number 
SGEC, 10-24 
CI-DSSI Overview, 11-3 
arbitration and selection, 11-4 
command-out phase, 11-4 
move data, 11-3 
RSPQ, 11-4 
Clock 
host maximum time window, 10-16 
Collision 
force mode, 10-20 
Command 
qualifier 
definition of, 12-26 
Command Address Specifiers, 12-29 
Commands 
BOOT, 12-35 
!-Comment, 12-78 
CONFIGURE, 12-37 
CONTINUE, 12-38 
DEPOSIT, 12-39 
EXAMINE, 12-41 
FIND, 12-44 
HALT, 12-45 
HELP, 12-46 
INITIALIZE, 12-49 
MOVE, 12-50 
NEXT, 12-52 
REPEAT, 12-54 
SEARCH, 12-55 
SET, 12-58 
SHOW, 12-62 
START, 12-67 
TEST, 12-68 
UNJAM, 12-72 
X Binary Load/Unload, 12-73 
XDELTA, 12-75 
!- Comment, 12-78 
Configuration, 2-1 to 2-7 
DSSI, 2-3 
CONFIGURE, 12-37 
CONFIGURE command, 2-3 
Console 
command 
keywords, 12-27 
qualifiers, 12-28 
commands, 12-34, 12-79 
syntax, 12-26 
VAX not supported, 12-27 
numeric expression radix specifiers, 12-28 
qualifiers, 12-81 
services provided, 12-1 
symbolic references, 12-29 
CONSOLE 
Serial Line, 7-1 
Console Registers, 7—1 


Console Connector, G—7 
Console Control Characters, 12-23 
Console Error Messages 
invalid characters, 12-26 
Console I/O mode, 12-87 
Console Module, 1-8 
Console Program Mode, 12-87 
Console Symbolic Addressing, 12-29 
CONTINUE, 12-38 
in restoring context, 12-7 
Control functions, F—32 
CQBIC, 1-7 
cache, 9-6 
Cycles 
asynchronous DMA read, 9-3 
demand Q22-bus read, 9-14 


D 


DEAR, see DMA Error Address Register 
DMA Error Address Register, see Registers 


DMA System Error Register, see Registers 
Data Buffers, 10-3 
Data Chaining 
disable mode, 10-20 
datagram 
definition of, 11-3 
Data transfer bus cycles, F-5 
DATBI bus cycle, F-—22 
DATBO bus cycle, F-24 
DC243, 141 
DC244, 14 
DC246, 1+ 
DC527, 1- 
DC541, 1+ 
DC542, 1- 
DEPOSIT, 12-39 
Descriptor Chaining 
defintion of, 10-28 
Descriptor List 
address registers, 10-9 
definition of, 10-28 
format, 10-28 
setup frame, 10-39 
Descriptor Lists, 10-3 
Device addressing, F—7 


NNN POD 


Device Dependent Bootstrap Procedures, 12-18 


Device priority, F-26 
Diagnostic Executive 
as used for error reporting, 12-83 
definition of, 12-83 
Diagnostic Interdependancies, 12-85 
Diagnostics, 12-83 


Digital’s Systems Communications Architecture, 


11-2 
Direct memory access, F-—17 


DMA guidelines, F—25 
DMA protocol, F-17 
DNA CSMA/CD, 10-52 


DNA Maintenance Operations Protocol (MOP), 


12-20 

Doorbell Interrupt Requests, 9-9 
DSSI 

as related to SCA, 11-2 

bus length, 2-7 

bus termination, 2-7 

cabling, 2-7 

configuration, 2-3 

drive order, 2-3 

node ID, 2-3 

node name, changing, 2-4 

unit number, changing, 2-5 
DSSI Bus Interface, 11-1 


E 


Empty Envelopes 
definition of, 11-2 
Environment, 12-86 
EPROM 
mapping, 12-86 
Errors 
main memory read, 9-8 
memory, 9-14, 10-14 
messages 
console, 12-26 
incorrect boot device name, 12-14 
non-recoverable, 9-8 
Q22-bus address space, 9-8 
Q22-bus parity, 9-14 


reported before console is established, 12-84 


SGEC address filter RAM, 10-12 
SGEC parity, 10-14 
SGEC RAM, 10-12 
SGEC ROM, 10-12 
SGEC self-test loopback error, 10-12 
SGEC transmit FIFO error, 10-12 
ERR_L, 10-14 
Ethernet 
control access technique, 10-2 
multicast address 
definition of, 10-2 
node priority, 10—2 
Overview, 10-1 
physical address 
definition of, 10-2 
types of network addresses, 10-2 
Ethernet connector, 1-8 
Ethernet Interface, 1-7 
EXAMINE, 12-41 
Examples 
Imperfect Filtering Buffer, 10-43 
perfect filtering buffer, 10—42 
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Exception 
definition of, 3-29 


Host Communication Area, 10-3 
Host System Crash Note, 10-6 


F I 

Files—11 lookup, 12-19 T/O buses, 1-6 

FIND, 12-44 Imperfect Filtering Buffer, 10-43 

Firmware Imperfect Filtering Setup Frame Buffer, 10-42 


block diagram, 12-3 
internationalization, 12-88 
overview, 12-1 
reasons for invocation, 12-1 
services, 12-87 
terminology, 12-1 
Firmware ROMs, 1-6 
Flags 
POWER AUX, 9-11 
POWER OK, 9-11 
restart in progress, 12-22 
FLINK 
definition of, 11-4 
Formats 
Buffers, 10-28 
Descriptor, 10-28 


G 


Good Memory, 12-18 


H 


H3602 
Ethernet connect options, 10-1 
H3604, 1-8 
Halt, F-32 
auxiliary, 9-9 
definition of, 12-23 
dispatch, B-1 
dispatch code, 12-5 
entry code, 12-4 
exit code, 12-7 
external, 12-6 
information saved on a, 12-4 
registers set to pre_determined value on a, 
12-4 
HALT, 12-45 
on bootstrap failure, 12-17 
Halt Actions 
restoring context, 12-7 
summary, 12-5 
Halt Code_3, 9-12 
Hard Error 
caused by writing the QBEAR, 9-15 
Hardware, 12-86 
Hardware Reset, 9-12 


HELP, 12-46 
Hit 
global, 9-3 
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INIT, 12-12 
Initialization, F-32 
following a processor halt, 12-22 
prior to bootstrap, 12-12 
SGEC, 10-11 
INITIALIZE, 12-49 
Installation, 2-1 to 2-7 
Instructions 
Return From Interrupt or Exception (REI), 
12-7 
Interprocessor Communication Facility, 9-8 
Interrupt 
BR7-4 disabled, 9—10 
doorbell request, 9-9 
priority, 10-7 
Receive Watchdog Timer, 10-13 
SGEC Transmit Watchdog Timer, 10-13 
SGEC vector, 10-7 
Interrupt protocol, F—27 
Interrupts, 3-29, F—25 
definition of, 3-29 
SGEC, 10-47 
Interrupts and Exceptions, 3-29 
Interval Timer Interrupt Request, 9-10 
Intrabackplane bus wiring, F-35 
IPCR, see Interprocessor Communication Register, 
9-8 
IPL 14, 9-9 
IPL_14, 10-7 
IPL_15, 10-7 
IPL_16, 10-7 
IPL_17, 9-9, 10-7 
IPL_17-14, 9-1 
IPL_31, 12-13 


K 


KA680 Cache 
Memory Hierarchy, 4-1 
KA680 CPU Module 
photograph, 1-2 


L 


Languages 
list of, 12-86 
Load definition, F-—83 
Load NUmber Field, 12-21 
Local Memory Partitioning, 12-13 


Lost Error Address, 9-14 


Main Memory 
starting address, 9-5 
Manchester-encoded Format, 10-1 
Mapping Registers 
enabling, 9-7 
Mass Storage Interface, 1-7 
Memory 
Cacheable References, 4—2 
external access to, 9-9 
host communication area, 10-3 
Primary Cache 
Overview, 4-8 
Q22-bus address translation, 9-2 
Virtual Instruction Cache, 4-2 
MEMORY, 5-1 
Backup Cache 
Data Block Allocation, 4-23 
DMA Effects, 4-23 
External Process Registers, 4-24 
Overview, 4-19 
Primary Cache, 4-8 
Organization, 4-8 


Memory Control, 1-8 
Memory Control Subsystem, 1-7 
Memory Management, 3-24 
Memory Module, 1-8 
message 

definition of, 11-3 
MICSR2, 10-8 
Miss 

local, 9-3 
Missed Frame Count, 10-24 
modes 

pass bad frames, 10-20 
Modes 


address filtering, 10-20 
auxiliary note, 9-9 
auxiliary select, 9-12 
boot message enable, 10-17 
console I/O, 12-87 
disable data chaining, 10-20 
force collision, 10-20 
program, 12-87 
SGEC operating, 10-13 
single cycle enable, 10-17 
Mode Switch, 12-8 
query, 12-9 
Module 
configuration, 2-2 
order, in backplane, 2-1 
Module contact finger identification, F-39 
MOM$LOAD, 12-20 
MOP functions, E-2 


MOP program load sequence, 12-20 
MOVE, 12-50 

MS690, 1-8 

Multicast Address Filter Mask, 10-3 
Multicast-group Address, 10-3 


N 


ROM 

Network Bootstrap 

synchronizing the load sequence, 12-21 
Network Interface, 10-1 

Network Interface Station Address ROM, 
Network listening, E-1 

NEXT, 12-52 

in restoring context, 12-7 

NICSR 

read, 10-5 

write, 10-5 

NICSRs, 10-3 

Normal, 12-8 

NVAX 

memory subsytem, 4-1 

NVRAM 

CPMBX, A-1 

partitioning, A-1 


O 


NI Command and Mode Registers, see Registers 
NISA, see Network Interface Station Address 


10-3 


OCP 
cabling, 2-7 
120-Ohm Q22-bus, F-33 
Operating Modes 
for port driver commands, 10-16 
Operating System (OS) 
restarting a halted, 12-22 
Operating System Restart 
defintion of, 12-22 
Operating Systems, 12-87 
Operator console panel 
See OCP 
Overview 
Ethernet, 10-1 


P 


Port Command Queue 0 Control Register, see 


Registers 


Port Command Queue 1 Control Register, see 


Registers 


Port Command Queue 2 Control Register, see 


Registers 


Port Command Queue 3 Control Register, see 


Registers 
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Port Datagram Free Queue Control Register, see 
Registers 

Port Disable Control Register ,see Registers 

Port Enable Control Register ,see Registers 

Port Error Status Register, see Registers 

Port Failing Address Register, see Registers 

Port Initialize Control Register ,see Registers 

Port Maintenance Control and Status Register, see 

Registers 

Port Maintenance Timer Control Register ,see 

Registers 

Port Maintenance Timer Expiration Control 

Register ,see Registers 

Port Message Free Queue Control Register ,see 
Registers 

Port Parameter Register, see Registers 


Port Status Register, see Registers 


Port Status Release Control Register, see Registers 
Page Frame Number Bitmap, 12-20 
Parity 

error address, 9-15 
pass Bad Frames Mode, 10-20 
Perfect Filtering Buffer 

example, 10-42 
Perfect Filtering Setup Frame Buffer, 10-40 
PFN bitmap, 12-12 
Physical NICSRs, 10-5 
Pointers 

Interrupt Stack(ISP), 12-7 
Port Driver 

definition of, 10-3 
Power Loss, 12-9 
Power status, F—32 
Power supply loading, F-39 
power-up 

memory layout, D-1 
Power-up 

diagnostics, 12-83 

mode switch, 12-8 

OS restart not supported, 12-6 
PR$_SAVPC, 12-4 
PR$_SAVPSL, 12-4 
PR$_TBIA, 12-7 
PRAO, 12-20 
Primary Bootstrap, 12-16 
PROCESS 

Definition of, 3-23 
Processor Initialization 

and the Q22-bus map, 9-10 
Processor Number 

as contained in the SCR, 9-11 
Programing 

SGEC, 10-3 
PROGRAMMABLE TIMERS, 7-8 
Public Call-in Routines, 12-86 
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Q 


Q22-bus Error Address Register, see Registers 
Q22-bus 
address space error, 9-8 
error handling, 9-16 
interface, 9-1 
cache, 9-5 
interprocessor communications facility, 
9-8 
supported functions, 9-1 
interrupt handling, 9-10 
map, 9-2 
map cache, 9-6 
map configuration, 9-10 
mapping, 9-3 
see also Registers, Q22—-bus Map Register 
enable, 9-5 
protecting note, 9-5 
Q22-bus electrical characteristics, F—32 
Q22-bus four-level interrupt configurations, F—31 
Q22-bus Interface, 1-7 
Q22-bus Map Cache 
flushing, 9-10 
Q22-bus Memory 
and VMB, 12-17 
Q22-bus signal assignments, F-2 
Query, 12-8 
Queued 
definition of, 10-38 


R 


Read 
NICSR, 10-5 
Receive 
buffer unavailable, 10-14 
Receive Descriptors, 10-28 to 10-33 
Receive Interrupt, 10-14 
Receive Polling Demand, 10-8 
Receive Watchdog Timer Interrupt, 10-13 
Reception 
start/stop, 10-18 
References 
DMA to main memory, 9-2 
to Processor Registers and Memory, 12-33 
Registers, 6-8 
Boot Message 
NICSR11, 10-25 
NICSR12, 10-25 
NICSR13, 10-25 
CI port, 11-6 
Diagnostic Breakpoint (NICSR14), 10-26 
DMA Error Address, 9-15 
DMA System Error, 9-12 
error reporting, 9-12 
for Q22-bus control, 9-1 


Registers (cont’d) 


initializing the general-purpose, 12-12 
Interprocessor Communication, 9-2, 9-8 
IPR 55, 9-7 
Monitor Command, 10-26 
Monitor Command(NICSR15), 10-26 
Network Interface, 10-3 
NI Command and Mode (NICSR6), 10-16 
NICSR5 status report, 10-15 
Polling Demand (NICSR1), 10-7 
Port Command Queue 0 Control, 11-14 
Port Command Queue 1 Control, 11-14 
Port Command Queue 2 Control, 11-14 
Port Command Queue 3 Control, 11-14 
port control, 11-13 
Port Datagram Free Queue Control, 11-14 
Port Disable Control, 11-15 
Port Enable Control, 11-14 
Port Error Status, 11-11 
Port Failing Address, 11-12 
Port Initialize Control, 11-15 
Port Maintenance Control and Status, 11-15 
Port Maintenance Timer Control, 11-15 
Port Maintenance Timer Expiration Control, 
11-15 
Port Message Free Queue Control, 11-14 
Port Parameter, 11-13 
Port Status, 11-8 
Port Status Release Control, 11-14 
Q22-bus Error Address, 9-14 
Q22-bus Map, 9-3 
accessing, 9-5 
cached copy, 9-6 
Q22-bus Map Base Address, 9-10 
Q22-bus Map Registers, 9-2, 12-17 
Revision Number and Missed Frame Count 
(NICSR10), 10-24 
saved by the console, 12-33 
SGEC command and status, 10-4 
SGEC status, 10-11 
SHAC, 11-5 
SHAC Shared Host Memory Address, 11-17 
SHAC Software Chip Reset, 11-17 
SHAC specific, 11-16 
system base (NICSR7), 10-21 
System Configuration, 9-11 
Time-Of-Year Clock, 7—7 


REGISTERS 


General Purpose, 3-1 
Internal Processor, 3-1, 3-3 
processor, 3-1 


Restart, 12-22 
Restart Parameter Block (RPB) 
RIP flag, 12-22 
Revision Number, 10-24 
RF-series disk drive 
access to firmware through DUP, 2-6 
cabling, 2-7 
RPB 
initialization, B—4 
RPB Signature Format, 12-23 
Runt Packets 
definition of, 10-2 


S 


SCR, see System Configuration Register 


SGEC, see Second Generation Ethernet Controller 


SHAC, see Single Host Adapter Chip 


SHAC Shared Host Memory Address, see Registers 
SHAC Software Chip Reset Register, see Registers 


Status Register, see Registers 
System Configuration Register,see Registers 
SCA 
as related to DSSI, 11-2 
Scatter-gather 
mapping, 9-1 
Script 
definition of, 12-83 
SEARCH, 12-55 
Secondary Bootstrap, 12-16 
Second Generation Ethernet Controller, 10-1 
burst limit mode, 10-17 
command and status registers, 10-4 
determining operating mode, 10-7 
internal processor updates, 10-16 
interrupt enable mode, 10-16 
loopback modes, 10-51 
operating mode, 10-13 
physical NICSRs, 10-5 
processes, 10-3 
programming sequence example, 10-3 
reception process, 10-12, 10-48 
reset, 10-16, 10-46 
self test, 10-16 
self-test timing note, 10-12 
startup procedure, 10-47 
states, 10-3 
transmission process, 10-12, 10-49 
virtual NICSRs, 10-5 
Selecting 


Registers Port Queue Block Base, 11-6 Q22-bus map register, 9-5 
REPEAT, 12-54 Self-test 


REQ MEM_LOAD, 12-21 SGEC, 10-12 

REQ PROGRAM, 12-21 SET, 12-58 

Reset Setup Frame, 10-38 
SGEC, 10-46 first, 10-38 


subsequent, 10-38 
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SGEC, 1-7 
SHAC, 1-7 
SHOW, 12-62 
Signal level specifications, F-—33 
Signature Block 

PROM, 12-20 
Single Cycle Enable Mode, 10-17 
Single Host Adapter Chip (SHAC) 

its role as a CI port, 11-3 

on chip buffering, 11-2 

on chip RISC, 11-2 

principal tasks, 11-3 
Socketted ROM, 10-3 
Software, 12-87 
START, 12-67 

in restoring context, 12-7 
Start/Stop Reception, 10-18 
Start/Stop Transmission, 10-17 
System Base Address, 10-22 
System configurations, F—36 
System Support Subsystem, 1-5 


T 


TBIA, 12-7 
Test, 12-8 
TEST, 12-68 
Test Mode 
SGEC, 10-27 
Timeout 
as detected by the Q22-bus interface, 9-1 
Timers 
Q22-bus interface NO GRANT, 9-16 
Q22-bus interface nonexistent memory, 9-16 
Q22-bus interface NO SACK, 9-16 
that restrict XMIT/RECV time, 10-22 
Translation Buffer, 3-24 
Transmission 
start/stop, 10-17 
Transmission Process State Transitions, 10-50 
Transmit Descriptor, 10-33 to 10-38 
built as a ring, 10-9 
Transmit Interrupt, 10-15 
Transmit Polling Demand, 10-7 
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Transmit watchdog timer interrupt, 10-13 


U 


Undeliverable Message, 11-4 
UNJAM, 12-12, 12-72 
Users, 12-86 


V 


Valid Maps, 12-17 
VAX-11 code, 12-1 
VAXELN 
and VMB, 12-16 
VAX system page table, 10-21 
Vector_204, 9-9 
VIC 
Data Register, 4-6 
Tag Register, 4—5 
VIC Cache Row Format, 4-3 
Virtual Instruction Cache 
Internal Processor Registers, 4—4 
Virtual Instruction Cache Organization, 4-3 
Virtual Memory Address 
Register, 4-4 
Virtual Memory Boot (VMB), 12-16 
definition of, 12-16 
Virtual NICSRs, 10-5 
VOLUNTEER, 12-21 


W 


Warmstart, 12-22 
Watchdog Timer 
SGEC, 10-23 
Write 
NICSR, 10-5 


X 


X - Binary Load and Unload, 12-73 
XDELTA, 12-75 


